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ABSTRACT 


This  thesis  addresses  the  need  for  a  navigation  and  shiphandling  game-based 
training  system  at  naval  academies.  The  Yard  Patrol  Simulator  (YPSim)  is  an 
application  designed  to  reduce  the  knowledge  gap  between  classroom  instruction 
and  hands-on  training  onboard  naval  academy  training  boats  (YPs).  The  goal 
was  to  develop  a  proof-of-concept  game-based  simulator  that  uses  3D  graphics 
to  replicate  basic  tasks  executed  onboard  the  YPs.  Two  missions  were  selected 
for  a  brief  task  analysis  study  to  determine  the  design  of  the  respective  game 
scenario  and  requirements.  The  design  process  involved  in  building  user 
interface,  physics  model,  3D  models,  and  artificial  intelligence  actors  are 
described  in  this  work.  For  thesis  purposes,  YPSim  was  designed  using  the 
Brazilian  Naval  Academy’s  YP  as  a  training  framework  development 
environment.  Using  a  sample  of  the  final  end  user  population,  we  conducted  a 
user  acceptance  study  of  proof-of-concept  version  of  YPSim  (v0.14)  at  the 
Brazilian  Naval  Academy.  The  findings  in  this  work  can  be  generalized  to  any 
other  naval  academy  or  institution  where  basic  navigation  and  shiphandling 
instruction  is  provided.  Initial  results  from  a  prototype  implementation  of  YPSim  at 
the  Brazilian  Naval  Academy  provided  insights  into  the  potential  use  of  this 
training  system. 
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I.  INTRODUCTION 


A.  MOTIVATION 

Most  of  my  career  as  a  Surface  Warfare  Officer  (SWO)  at  the  Brazilian 
Navy  was  dedicated  to  shiphandling  and  navigation  instruction.  Between  2004 
and  2009,  I  was  stationed  as  a  deck  officer  and  shiphandling  instructor  at  the 
Brazilian  Navy  Tall  Ship  “Cisne  Branco,”  receiving  around  300  midshipmen  per 
year  for  instructions  on  board.  In  2009,  I  was  assigned  Commanding  Officer  of 
one  of  the  three  Brazilian  Naval  Academy’s  (BNA)  Yard  Patrol  (YP)  crafts,  the 
“Guarda-Marinha  Jansen”  (U-1 1).  For  a  period  of  one  year,  I  was  responsible  for 
one-third  of  the  hands-on  training  activity  at  the  BNA,  which  was  a  fascinating 
experience.  Among  the  many  lessons  learned  during  my  job  as  an  instructor,  two 
are  remarkable  truths:  nothing  substitutes  for  a  motivated  student  in  the 
audience,  and  time  will  always  be  a  constraint  if  you  expect  your  student  to  really 
master  a  learning  objective. 

As  a  result  of  many  observations  during  the  several  training  missions 
accomplished  on  board,  and  conversations  with  my  colleagues  at  the  BNA’s  YP 
fleet,  we  have  noticed  that,  in  general,  midshipmen  have  a  poor  understanding  of 
the  practical  tasks  executed  on  board  the  YPs.  The  YP  is  a  ship  designed  to  play 
an  important  role  as  an  afloat  laboratory  for  the  courses  related  to  navigation, 
shiphandling  and  naval  operations.  It  is  a  place  for  the  experimentation  and 
practice  of  concepts  too  abstract  to  learn  without  reinforcements  coming  from 
trial-and-error  practice.  However,  my  colleagues  and  I  observed  that  a  huge 
knowledge  gap  was  present  between  lectures  and  procedures  manuals,  and  the 
afloat  lab,  the  YP.  Without  any  intermediate  steps  providing  the  basic  skills 
required  to  play  the  roles  on  board,  midshipmen  became  easily  overwhelmed  by 
the  huge  amount  of  new  information  needed  for  every  practice  onboard.  This 
overwhelming  sensation  affects  the  midshipman’s  motivation  and  consumes  the 
instructor’s  time  in  teaching  the  very  basics  steps.  Instead  of  focusing  100%  of 
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the  allocated  time  on  hands-on  training  in  the  real  learning  objectives,  the  YP’s 
instructors  had  to  share  time  with  minor  details  that  consumed  most  of  the 
restricted  schedule. 


A  U.S.  Navy  lieutenant  stationed  as  navigation  instructor  at  BNA  reported 
something  similar  when  he  was  a  midshipman  at  the  United  States  Naval 
Academy  (USNA).  After  leaving  the  BNA  and  becoming  a  student  at  NPS,  I  have 
also  talked  to  U.S.  Navy  officers  who  reported  the  same  issues  when 
midshipmen  at  the  USNA.  The  similarities  presented  in  both  learning  frameworks 
of  BNA  and  USNA  pushed  me  towards  the  present  work.  This  thesis  represents 
an  attempt  to  reach  a  proof  of  concept  for  a  new  tool  intended  to  reduce  the 
knowledge  gap  observed  between  classroom  and  hands-on  training  at  the  YPs. 


Figure  1 .  Real  and  Virtual  BNA's  YP. 


B.  OBJECTIVE 

The  primary  objective  of  this  thesis  is  to  provide  the  design  and  a  proof-of- 
concept  prototype  of  a  PC  game-based  simulator  for  navigation  and  shiphandling 
tasks  carried  by  a  generic  naval  academy’s  midshipmen  onboard  YPs.  The 
secondary  objective  is  the  ability  to  extend  this  application  as  an  instructional 
resource  in  the  classroom  as  a  medium-scale  simulator. 
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c. 


APPROACH 


To  achieve  the  proposed  objectives,  this  thesis  is  conducted  in  four  major 
steps:  review,  task  analysis,  development,  and  test  with  refinements. 

First,  using  the  BNA  environment  as  an  example,  a  broad  introduction  of 
navigation  and  shiphandling  instruction  is  presented,  along  with  a  brief  review  of 
cognitive  aspects  of  learning  game-based  systems  and  current  simulations.  The 
second  step  is  towards  the  identification  of  onboard  midshipmen  activities  that 
are  interesting  enough  to  be  simulated  in  the  game,  called  the  YP  Simulator  (or 
shortened  to  “YPSim”).  A  task  analysis  of  two  selected  missions  is  performed, 
providing  instructional  guidance  to  a  requirements  section  of  the  thesis.  Following 
these  requirements,  the  third  step  is  the  development  of  the  game  platform,  using 
Delta3D  open  source  game  engine.  With  a  prototype  version  available,  the  fourth 
and  final  step  is  taken,  leading  to  user  acceptance  test  results  at  BNA.  Based  on 
feedback  collected  from  the  user  study,  software  refinements  are  applied  to  the 
original  code,  ending  the  design  cycle  proposed  for  the  scope  of  this  thesis. 

D.  CHAPTER  OUTLINE 

1.  Introduction 

This  chapter  presents  a  brief  explanation  of  the  research  problem  and 
respective  steps  taken  to  address  it. 

2.  Background 

In  the  Background  chapter,  we  first  describe  in  details  the  current 
navigation  and  shiphandling  instruction  framework  commonly  adopted  at  naval 
academies  using  YPs.  Secondly,  a  description  of  the  cognitive  process 
developed  by  midshipmen  onboard  the  YP  is  given,  providing  a  better 
understanding  of  the  operational  side  of  the  problem.  The  next  step  was  to 
provide  a  general  idea  of  few  current  game-based  simulations  systems 

developed  for  similar  training  purposes,  ending  with  a  brief  conclusion. 
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3. 


Missions  Description  and  Cognitive  Task  Analysis 


This  chapter  introduces  the  description  of  the  basic  training  missions 
performed  onboard  the  BNA  YPs,  the  cognitive  task  analysis  of  two  selected 
missions,  including  critical  cues  inventory  and  performance  metrics. 

4.  Requirements  Analysis 

The  YPSim’s  requirements  analysis  are  presented  in  this  chapter,  defining 
costumers  needs,  objectives  as  a  system  and  planned  environment. 

5.  System  Development 

This  chapter  describes  the  research  effort  towards  the  development  of 
YPSim  functionality,  models,  and  basic  components  that  lead  to  YPSim  v0.14, 
the  proof  of  concept  prototype  version  of  the  product. 

6.  YPSim  Testing 

The  releases  of  testing  versions  of  YPSim  are  documented,  presenting  the 
most  important  milestones  for  exposing  the  product  to  the  public  and  collecting 
feedback  for  software  refinements. 

7.  User  Acceptance  Survey 

This  chapter  describes  a  user  acceptance  survey  conducted  at  the  BNA 
with  40  midshipmen  who  used  YPSim  in  a  lab  room.  We  describe  the  method 
and  results  involved  in  this  important  study  to  evaluate  system’s  design  using 
end  users  feedback. 
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II.  BACKGROUND 


A.  NAVIGATION  AND  SHIPHANDLING  INSTRUCTIONS 

Considered  a  mix  of  science  and  art  (Barber,  2005),  navigation  and 
shiphandling  are  traditional  aspects  of  any  naval  academy’s  body  of  knowledge. 
Not  only  do  naval  academies  offer  courses  related  to  these  two  subjects,  but  any 
other  institution  that  deals  with  seamanship  courses  would  include  navigation 
and  shiphandling  in  the  curriculum.  Various  approaches  are  used  to  teach  such 
topics  and  allow  the  students  to  reach  the  learning  objectives.  For  the  scope  of 
this  thesis,  we  are  interested  in  a  broad  type  of  instruction  provided  by  several 
naval  academies  worldwide,  such  as  the  United  States  Naval  Academy  (USNA) 
and  the  Brazilian  Naval  Academy  (BNA).  Both  academies  adopt  a  system  that 
relies  on  classroom  theory  followed  by  hands-on  training  onboard.  This  thesis 
adopts  the  instruction  model  used  at  BNA,  assuming  that  it  is  similar  enough  to 
USNA’s  approach.  We  expect  that  all  findings  derived  from  this  design  can  be 
generalized  to  any  institution  that  uses  a  similar  framework. 

The  first  step  towards  navigation  and  shiphandling  instruction  happens 
inside  the  classroom.  Instructors  present  the  contents  of  the  disciplines  as  they 
would  any  other  regular  core  course,  e.g.,  physics,  calculus  or  programming,  as 
a  lecture.  Inside  a  classroom  is  where  most  midshipmen  will  have  their  first 
exposure  to  subjects  related  to  shiphandling.  However,  without  having  any 
experience  aboard  a  ship,  this  theory  becomes  confusing  and  is  often  too 
abstract  to  be  comprehended.  As  any  other  discipline  that  involves  complex 
concepts,  a  solid  understanding  requires  a  lab. 

The  second  step  is  the  hands-on  training.  Through  test  and 

experimentation  onboard  the  academy’s  YPs,  midshipmen  solidify  the  abstract 

concepts  presented  in  the  classroom.  The  YPs  are  the  academy’s  navigation  and 

shiphandling  laboratories.  Onboard  the  YPs — and  playing  roles  as  helmsman, 

navigator,  lee-helmsman,  radar  operator,  or  the  Officer  of  the  Deck  (OOD) — the 
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midshipmen  are  able  to  start  developing  their  mental  model,  based  on  practical 
observation  of  real  events  related  to  the  classroom  theory.  The  mental  model 
definition  applied  here  is  the  one  given  by  Hackos  (1998)  as  something  vague, 
individual  and  dynamic,  which  represents  a  collection  of  associations  in  people’s 
minds,  used  to  make  connections  between  known  and  learned  information. 


Figure  2.  Midshipmen  during  hands-on  training  at  USNA  (left)  and 

BNA  (right)  YP  bridges. 


Although  this  classroom/YP  combination  seems  powerful  from  an 
instructional  perspective,  some  factors  can  limit  its  potential  benefits,  as  listed 
below: 

•  Total  time  per  midshipman  aboard  the  YP  is  low. 

•  The  fraction  of  the  already  small  amount  of  YP  time  in  certain  key 
roles  is  low  as  well. 

•  The  most  important  consideration  may  be  the  knowledge  gap 
between  the  classroom  and  the  hands-on  training.  A  considerable 
amount  of  time  and  dedication  is  needed  to  familiarize  a 
midshipman  with  the  new  controls,  procedures,  displays  and 
organization  onboard.  Very  often,  onboard  instructors  spend  a 
relatively  large  amount  of  time  teaching  very  basic  skills  preparing  a 
team  of  midshipmen  to  train  for  the  objective  tasks. 

Over  many  years  of  use  in  institutions  such  as  the  USNA  and  the  BNA, 
the  learning  framework  using  classroom  and  hands-on  training  has  proven  to  be 
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very  powerful.  Ensigns  who  graduate  from  the  USNA  (receiving  extensive 
training  through  the  YPs)  and  reported  to  SWOs,  demonstrate  higher 
comprehensive  shiphandling  skills  when  compared  to  the  NROTC  Ensigns 
(Grassi,  2000).  This  thesis  is  not  intended  to  provide  any  new  model  for  the 
navigation  and  shiphandling  instruction  at  naval  academies,  but  to  present  a 
solution  to  mitigate  or  minimize  the  effects  of  one  of  the  issues  with  the  current 
framework.  Providing  a  new  instructional  tool  that  is  able  to  reduce  the 
knowledge  gap  between  the  theory  and  practice  would  represent  an  important 
step  towards  improvements  in  the  framework,  reducing  costs  and  loss  of  time 
during  training.  This  thesis  is  about  the  design  of  a  simulator  for  the  very  basic 
tasks  executed  during  the  hands-on  training.  Using  a  game-based  system 
approach  and  open  source  libraries,  a  low-cost,  easily  accessible  PC-simulator 
can  be  used  to  entertain,  motivate  and,  at  the  same  time,  introduce  the  basics  of 
the  tasks  conducted  onboard  the  YP. 

B.  COGNITION  ONBOARD  THE  YP 

To  better  understand  the  issues  here  addressed,  this  section  provides  a 
brief  analysis  of  the  YP  as  a  cognitive  adaptive  system,  as  proposed  by  Hutchins 
(1995).  In  his  book  “Cognition  in  the  Wild”  Dr.  Hutchins  makes  a  deep  scientific 
exploration  of  the  navigation  tasks  executed  onboard  a  U.S.  Navy  ship, 
concluding  the  following: 

The  conduct  of  the  activity  creates  elements  of  representational 
structure  that  survive  beyond  the  end  of  the  task.  These 
elements — the  logbooks,  pencil  marks  on  charts,  the 
quartermasters’  memories  of  the  events — are  the  operational 
residua  of  the  process.  In  this  adaptive  system,  the  media  may  be 
changed  by  the  very  processes  that  constitute  the  conduct  of  the 
activity.  The  operations  of  the  navigation  team  produce  a  structured 
experience  for  the  participants  that  contains  opportunities  for 
individual  learning.  As  a  consequence  of  their  participation  in  the 
task  performance,  the  quartermasters  may  acquire  internal 
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organization  that  permits  them  to  coordinate  with  the  structure  of 
their  surroundings.  In  this  way,  learning  can  be  seen  as  the 
propagation  of  organization  through  an  adaptive  system.  (Hutchins, 
1995) 


The  learning  observed  by  Hutchins  during  the  navigation  is  a  constant 
process  during  hands-on  training  onboard  the  YP.  The  YP  is  designed  for  that 
exact  purpose,  and  midshipmen — members  of  the  team — are  novices  who 
interact  with  the  system  structure  while  the  experimentation  and  observation 
transform  their  mental  model  of  the  task. 


Hands-on  Training 


Hands-on  Training 


Figure  3.  Neisser's  Perceptual  Cycle  from  a  midshipmen 

perspective  with  YPSim  incrementing  the  exploration  step. 


A  typical  example  of  the  importance  of  experimentation  in  building  a 
midshipman’s  mental  model  is  breaking  the  YP’s  inertia.  The  instructors  in  the 
classroom  present  numbers  and  tables  relating  to  a  ship’s  acceleration  in 
general.  These  numbers  will  have  a  meaning  to  the  midshipmen  associating  a 
given  engine’s  RPM  and  speeds.  If  the  numbers  are  presented  in  a  table,  the 
understanding  is  very  poor,  since  the  numbers  are  rarely  connected  to  any 
previously  registered  event.  Although,  when  the  instructor  presents  this 
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information  using  a  graph,  the  student  can  easily  correlate  the  acceleration  with 
the  slope  of  the  curve — something  that  he  has  previous  understanding  with  from 
math  and  physics  courses.  Going  further,  the  instructor  can  present  an  animation 
of  an  accelerating  ship  model  with  those  values,  and  the  understanding  will  be 
even  more  solid  and  easier  to  correlate  in  a  future  experience.  Now,  imagine  the 
student  feeling  the  same  acceleration  onboard  the  YP.  He/she  has  the 
opportunity  to  observe  the  OOD  giving  the  RPM  order  to  the  lee-helmsman,  the 
lee-helmsman  actuating  the  controls,  the  RPM  indicators  increasing,  the  ship  and 
the  surrounding  environment  beginning  to  move,  engine  noise  increasing,  wake 
at  the  stern  starts  increasing,  and  so  on.  All  this  sensory  information,  known  as 
cues,  will  be  part  of  the  mental  model  created  in  the  midshipman’s  mind  after  the 
experience.  As  supported  by  Hutchins,  the  use  of  experimentation  during  the 
process  facilitates  the  learning  and  building  of  a  mental  model  of  the  task 

The  cognition  involved  in  navigation  and  shiphandling  tasks  is  not  easily 
learned.  It  takes  a  considerable  amount  of  time  until  midshipmen  are  able  to 
master  a  given  seamanship  skill.  As  future  officers  who  will  be  soon  in  leadership 
and  decision-making  positions,  midshipmen  have  to  gather  a  solid  understanding 
of  all  sets  of  basic  seamanship  skills.  After  his  observational  study,  Hutchins 
understood  the  complexity  involved  in  learning  navigation  skills: 

The  development  of  the  practitioners  themselves  takes  years. 
Through  a  career,  a  quartermaster  gradually  acquires  the  skills  that 
are  exercised  in  the  performance  of  the  job.  Changes  to  the 
organization  of  the  internal  media  that  the  quartermaster  brings  to 
the  job  take  place  more  slowly  than  the  changes  to  the  states  that 
the  media  support.  That  is,  it  takes  longer  to  learn  how  to  plot  a  fix, 
for  example,  than  it  does  to  plot  a  fix.  But  since  most  learning  in  this 
setting  happens  in  the  doing,  the  changes  to  internal  media  that 
permit  them  to  be  coordinated  with  external  media  happen  in  the 
same  processes  that  bring  the  media  into  coordination  with  one 
another.  The  changes  to  the  quartermasters’  skills  and  the 
knowledge  produced  by  this  process  are  the  mental  residua  of  the 
process.  (Hutchins,  1995) 
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Most  of  the  midshipmen  joining  naval  academies  are  going  onboard  a  ship 
for  the  first  time  on  the  YPs.  All  the  basic  understandings  of  how  a  ship  works — 
its  organization,  its  dynamics  and  peculiar  procedures — start  from  zero  at  the  first 
or  second  year  of  academy.  To  better  associate  examples  provided  inside  the 
classroom,  and  execute  the  initial  roles  onboard,  the  students  need  practice, 
usually  coming  with  time  after  each  training  onboard.  The  use  of  a  system  like 
YPSim  would  certainly  help  to  start  building  this  basic  mental  model 
representation  of  the  YP,  producing  results  on  both  sides:  classroom  and 
onboard.  Providing  an  intermediate  level  of  experimentation  media,  YPSim  would 
provide  a  chance  to  enhance  the  midshipman’s  representation  of  the  YP  world 
and  stimulate  the  understanding  of  new  topics  in  the  classroom.  This  implies  that 
less  time  is  required  to  reach  a  desirable  knowledge  level  to  execute  tasks 
onboard,  either  individually  or  as  a  team. 

The  relevance  of  prior  experiences  in  a  given  environment  is  reinforced  by 
the  theory  of  Perceptual  Cycle.  Neisser  (1976)  explains  that  perception  is  a 
constructive  process  that  connects  an  anticipatory  schemata,  the  environment 
exploration,  and  information  acquired  by  modifying  the  schema.  First-year 
midshipmen  have  little  knowledge  to  build  a  navigation  schema  in  their  minds. 
Assuming  they  have  never  been  onboard  the  YP,  it  will  be  difficult  to  direct  their 
attention  to  the  correct  visual  information  necessary  to  execute  a  task.  If  he/she 
plays  the  role  of  helmsman  at  the  YP’s  bridge,  his  anticipatory  schemata  will 
direct  his  attention  to  the  wheel,  the  only  information  known  to  correlate  to  his/her 
task.  Information  available  from  the  compass,  rudder  angle  indicator,  and  the 
outside  world  are  probably  neglected  the  first  time.  The  novice  helmsman  does 
not  understand  that  new  cues  are  relevant  until  the  experimentation — sometimes 
directed  by  external  guidance  from  an  instructor — changes  his/her  anticipatory 
schemata.  Imagine  now  the  OOD  role,  usually  played  by  fourth-year  midshipmen 
who  are  more  experienced  onboard.  It  takes  time  to  construct  a  good  OOD 
schema,  one  that  drives  the  midshipman’s  attention  to  the  proper  set  of  cues 
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available  at  the  YP’s  bridge.  YPSim  represents  a  supplementary  source  of 
experimentation  in  a  virtual  environment  presentation  of  the  world  to  be  explored. 

C.  CURRENT  GAME-BASED  SIMULATIONS 

One  of  the  first  paragraphs  of  Naval  Shiphandler’s  Guidebook  concerns 
the  advancements  of  simulation  in  shiphandling  training: 

The  most  important  and  valuable  advancements  in  shiphandling 
training  has  been  the  introduction  of  shiphandling  simulators.  More 
than  fifty  simulators  that  meet  international  standards  exist  in  the 
United  States,  and  there  are  more  than  two  hundred  worldwide.  In 
addition  to  these  full-sized  devices,  there  are  countless  simulators 
of  lesser  capability,  as  well  as  model  boat  basins,  that  offer 
valuable  training  opportunities  for  shiphandlers  to  learn  and  to 
improve  proficiency.  (Crenshaw,  1975) 

According  to  Caird  (1996),  “visual  simulation”  is  a  3D  graphic  image 
generated  by  computers  to  create  a  cognitive  and  physical  interaction  (Caird, 
1996).  This  interaction  is  represented  by  the  cognitive  and  physical  real-time 
participation  of  the  user  in  the  environment  (Salvatore,  2005).  Bringing 
immersion,  interaction  and  presence  into  a  virtual  environment  that  represents 
the  working  world  where  navigation  and  shiphandling  take  place,  trainees  can 
experiment  and  practice  skills  in  a  controlled  physical  situation.  The  simulation 
benefits  for  training  are  largely  explored  in  previous  works  ( e.g .,  Norris,  1998; 
Grassi,  2000;  Brannon  and  Villandre,  2002;  McDonough  and  Strom,  2005; 
Salvatore,  2005;  Ernst,  2006,  Toledo,  2006;  Rodrigues,  2010;  Brown,  2010). 

In  the  past,  shiphandling  simulators,  often  called  Bridge  Simulators,  were 

associated  with  large  hardware  infrastructure  capable  of  rendering  3D  graphics 

and  computing  an  acceptable  physics  model  of  the  simulated  ship.  Today’s 

reality  is  different,  and  a  commercial  computer  can  run  powerful  simulations  with 

the  same  characteristics  of  a  Bridge  Simulator  decades  ago  (Salvatore,  2005). 

The  Full  Mission  Bridge  Simulators  (FMBS),  where  trainees  physically  operate 

the  equipment  of  a  bridge  as  a  team,  are  still  in  use  and  represent  the  biggest 

effort  of  industry  in  this  arena.  FMBS  are  expensive  and  demand  a  large 
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personal  and  material  structure  to  operate,  making  a  team  training  a  big  event  in 
a  sailor’s  day.  A  cheaper  and  easily  accessible  alternative — although  for 
individual  training  only  and  less  realistic — is  the  PC-based  simulator.  Bridge 
simulations  running  in  conventional  PCs — referred  in  this  thesis  as  serious 
games  applications — are  a  perfect  solution  for  part  task  training,  individual 
training,  and  learning  basic  skills.  As  described  in  Section  A  (Navigation  and 
Shiphandling  Instruction),  midshipmen  needs  for  a  simulator  are  more  towards 
the  simplicity  and  accessibility  of  a  game-based  simulator  rather  than  an  FMBS. 
The  level  of  complexity  of  the  skills  intended  to  train  in  this  work  does  not  require 
the  use  of  an  FMBS.  This  thesis  focuses  its  attention  on  the  use  of  a  game- 
based  approach  to  address  issues  concerning  navigation  and  shiphandling 
instruction  at  naval  academies. 

Game-based  systems  are  defined  as  any  computer-supported  real-time 
system  that  couples  multiple  sensory  information  in  a  organized  way,  providing  a 
meaningful  context  for  human  action  and  collaboration  (Sadagic,  2010).  This 
definition  also  includes  the  following  elements  as  characteristics  of  a  game- 
based  system: 

•  Content:  representation  of  environment  (typically  3D),  actors  and 
characters  (one  or  many) 

•  Storyline:  giving  a  meaning  to  all  actions 

•  Roles:  all  actors  and  characters  have  them 

•  Tasks  and  goals:  well-defined  objectives 

•  Dynamics:  set  of  rules,  behaviors  and  interaction  modalities 

•  Competition:  levels,  teams,  scores 

Zyda  (2005),  Salvatore  (2005),  and  Ernst  (2006)  also  include  motivation 
and  involvement  as  key  factors  that  make  game-based  systems  more  attractive 
when  training  in  situations  where  primary  users  are  part  of  the  “wired”  generation. 
This  meets  the  purposes  of  YPSim,  primarily  designed  to  attend  young 
midshipmen  ranging  from  18  to  22  years  old.  By  leveraging  midshipmen 
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curiosity,  each  becomes  personally  motivated  to  learn,  creating  an  attitude  of 
intentional  learning,  resulting  in  the  retaining  of  useful  information  (Ernst,  2006). 

Experiences  from  games  are  capable  of  creating  stories  on  top  of  some 
pedagogical  content.  Using  stories  as  a  tool,  humans  can  gain  understanding, 
solidify  memory,  and  have  an  opportunity  to  tell  their  own  version  of  any  event 
(Beard,  2006).  While  playing  a  game,  users  can  make  connections  between 
theory,  concepts  and  ideas,  and  a  story  representing  these  abstractions  in  a 
meaningful  and  memorable  way.  These  connections  can  help  a  future  retrieval  of 
information  if  associated  with  any  significant  event  that  happened  during  the 
story  played  in  the  game.  Consider  a  situation  where  a  midshipman  executes  a 
mooring  task  in  a  simulation  game,  where  he  is  the  OOD  responsible  for  the  ship 
maneuver.  If,  during  the  pier  approach,  the  YP’s  speed  was  too  high,  thus 
resulting  in  a  collision  against  the  pier,  this  significant  event  can  be  registered  as 
a  story  in  a  mental  model  representation  that  could  be  retrieved  for  later  review 
and  correction. 

Mental  Simulation  and  Storybuilding  Mental  models  can  be  used  to 
mentally  project  into  the  future.  We  tell  ourselves  stories  about  the 
situation  as  it  unfolds,  and  we  mentally  explore  alternative, 
hypothetical  futures.  Whereas  mental  models  provide  a  causal 
understanding  of  how  situations  came  about  and  what  they  are  in 
the  present,  mental  simulation  involves  enacting  series  of  events 
and  pondering  them  as  they  lead  to  possible  futures.  Like  mental 
models,  mental  simulation  and  story  building  are  essential  to  sense 
making,  problem  detection,  and  decision  making.  (Crandall,  2006) 

The  accessibility  of  a  game-based  system,  installed  in  a  lab  desktop  or 
even  in  the  trainee’s  own  PC,  represents  a  big  advance  in  training.  Imagine  a 
midshipman  after  a  class  where  the  instructor  presented  some  theory  about 
mooring  a  ship.  This  task,  in  real  life,  requires  a  very  complex  set  of  skills  from 
the  OOD:  wind  and  current  perception,  engines  and  rudder  control,  twisting  and 
pivoting,  mooring  lines  handling,  etc.  If  the  midshipman  leaves  the  classroom 
with  doubts  about  the  “what  ifs”  scenarios  in  a  mooring  maneuver,  the  training 
aboard  the  YP  will  represent  the  only  place  to  experiment  and  clarify  his/her 
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knowledge.  If  an  FMBS  were  available  at  the  academy,  his/her  hypothesis  about 
the  maneuver  could  also  be  tested,  but  in  a  limited  amount  of  time  and 
depending  on  simulator  availability.  Under  the  supervision  of  instructors  and 
other  peers,  this  midshipman  would  typically  be  hesitant  to  make  mistakes  or  try 
nonsense  experiments  with  the  virtual  ship.  However,  these  pressures  and 
restrictions  do  not  exist  when  using  a  game-based  system  running  on  the 
midshipman’s  PC.  He/she  could  start  answering  questions  and  testing 
maneuvering  hypothesis  right  after  the  class,  without  any  delay  or  assistance. 

The  concept  of  using  game-based  ship  simulations  for  training  is 
increasing  dramatically  with  the  hardware  improvements  of  PCs.  The  advance  of 
multi-core  CPU  and  GPU  capabilities  is  opening  a  new  dimension  for  more 
detailed  physics  models  and  high-resolution  graphics  running  on  a  desktop  or 
even  a  laptop.  Three  applications  designed  for  seamanship  simulations  are 
relevant  to  the  scope  of  this  thesis  and  deserve  special  attention:  SurfTacs, 
Fleetman  Desktop,  and  Ship  Simulator. 


Figure  4.  SurfTac's  screenshots. 

SurfTacs  was  a  Master’s  Thesis  project  designed  by  Ernst  (2006)  at  NPS. 
Adopting  open  source  concepts  described  by  Salvatore  (2005),  SurfTacs  was 
developed  using  the  Delta3D  game  engine  as  main  library  infrastructure. 
SurfTacs  is  a  stand-alone  Division  Tactics  Simulator  (DIVTACS)  intended  to  train 
tactical  maneuvers  aboard  a  virtual  Arleigh-Burke  Class  Guided-Missile 
Destroyer  (DDG)  (SurfTacs,  n.d.).  SurfTacs  represented  a  proof-of-concept 
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implementation  of  a  game-based  systems,  using  Delta3D  game  engine,  to  partial 
task  train  for  OOD  tactical  skills.  Salvatore  (2005)  and  Ernst  (2006)  play  an 
important  role  in  the  design  of  YPSim.  YPSim  inspiration  comes  from  Salvatore’s 
configuration  and  architecture  for  an  open  source  simulation  using  Delta3D  and 
Ernst’s  proof-of-concept  implementation  of  SurfTacs.  Despite  the  fact  that  YPSim 
is  not  a  continuation  of  Ernst’s  work  in  SurfTacs,  both  share  the  same  concept  of 
a  game-based  system  using  Delta3D  infrastructure.  While  SurfTacs  is  designed 
for  tactical  maneuvers  aboard  a  DDG,  YPSim  focuses  on  navigation  and 
shiphandling  aboard  the  Naval  Academies’  YPs. 


Figure  5.  Fleetman  Desktop’s  screenshots. 


The  second  software  is  Fleetman  Desktop,  developed  by  DTM  Global,  a 
British  company.  The  Fleetman  family  of  bridge-training  simulators  is  designed 
for  team  training  types  of  scenarios.  The  Fleetman  Desktop  variant  offers 
individualized  training  for  OOD  skills  regarding  navigation,  radar  operation, 
contact  risk  managing  and  UNREP.  Fleetman  Desktop  is  a  proprietary  software 
used  by  naval  forces  including  the  UK  Royal  Navy,  Royal  Navy  Oman,  the  Royal 
New  Zealand  Navy,  and  Royal  Saudi  Naval  Forces.  Network  capabilities  offer 
options  of  missions  in  a  distributed  virtual  environment,  which  expands  the 
simulation’s  training  capabilities  and  instructor’s  guidance  (Fleetman  Desktop,  n. 
d.). 
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Figure  6.  Ship  Simulator’s  screenshots. 

The  last  seamanship  simulation  of  interest  in  this  work  is  the  Ship 
Simulator  family.  Ship  Simulator  is  a  commercial  software  developed  by  the 
VSTEP,  a  company  from  Holland.  Ship  Simulator  is  a  PC  game  simulator  usually 
associated  with  a  maritime  version  of  Microsoft’s  Flight  Simulator.  Ship  Simulator 
Extremes  is  the  revolutionary  latest  game  in  the  best-selling  Ship  Simulator 
Series.  Featuring  a  realistic  ocean  system,  advanced  dynamics  and  weather 
systems,  Ship  Simulator  offers  high-quality  graphics  representing  missions  where 
users  can  play  the  role  of  a  captain  in  several  types  of  ships  (Ship  Simulator,  n. 
d.).  Ship  Simulator  was  not  designed  primarily  as  a  training  tool;  rather,  it  was 
focused  on  the  entertaining  aspects  of  driving  a  ship  under  different  scenarios. 
Despite  its  original  purpose,  the  game  offers  fairly  realistic  conditions  of  a  ship’s 
dynamics  and  control  operations,  where  users  can  practice  numerous  ship¬ 
driving  skills. 

D.  CONCLUSION 

This  chapter  reviewed  basic  topics  required  for  a  better  understanding  of 
the  training  issues  and  respective  solutions  explored  in  this  thesis.  First,  the 
framework  for  navigation  and  shiphandling  instruction  adopted  at  USNA  and  BNA 
was  analyzed.  Assuming  the  similarities  between  frameworks  at  both  USNA  and 
BNA,  and  the  generalization  of  the  findings  in  this  research,  the  BNA  framework 
was  selected  as  a  reference  model  for  investigation  and  design  of  YPSim.  A 
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knowledge  gap  between  the  classroom  and  hands-on  training  instructions  was 
identified,  reducing  the  effectiveness  of  the  YP  as  a  training  resource.  Second, 
the  cognitive  process  involved  during  training  aboard  the  YP  was  explored. 
Referring  to  the  theory  of  perceptual  cycle  (Neisser,  1976),  the  use  of  part-task 
simulation  was  viewed  as  a  potential  solution  to  address  the  knowledge  gap 
issue.  Exposing  midshipmen  to  an  extra  exploratory  step  in  the  new  environment 
represented  by  the  YP  can  lead  to  a  rapid  change  in  their  schema,  leading  to  a 
better  mental  model  relative  to  the  tasks  covered  by  the  hands-on  training.  The 
third  topic  reviewed  concerned  the  game-based  systems  simulators  approach  as 
being  the  best  solution  for  the  type  of  system  needed  for  this  training  simulation 
solution.  A  brief  analysis  of  three  ship  driving  game-based  systems  (SurfTacs, 
Fleetman  Desktop  and  Ship  Simulator)  was  conducted.  YPSim’s  design  should 
be  guided  by  SurfTacs’  training  concept  and  architecture,  using  Delta3D,  adding 
the  graphical  appeal  and  game  structure  of  the  Ship  Simulator  family,  a 
challenging  task. 

In  order  to  raise  the  design  requirements  for  YPSim,  the  next  chapter 
presents  a  description  of  the  missions  executed  by  midshipmen  during  the 
hands-on  training  aboard  BNA’s  YPs.  From  the  set  of  missions  enumerated,  two 
of  them  will  be  selected  for  a  cognitive  task  analysis  study  from  the  perspective 
of  the  OOD.  The  design  requirements  will  be  guided  towards  a  maximization  of 
the  exploratory  steps  of  the  midshipman’s  perceptual  cycle,  presenting  the 
maximum  number  of  cues  involved  in  their  cognitive  processing. 
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III.  MISSION  DESCRIPTION  AND  COGNITIVE  TASK  ANALYSIS 


The  process  of  designing  a  training  system,  such  as  the  Yard  Patrol 
Simulator  (YPSim),  necessarily  involves  the  analysis  of  its  training  objectives. 
Providing  answer  to  the  following  questions  is  key  to  achieve  this  goal: 

•  Who  will  be  trained  by  the  system? 

•  What  do  they  need  to  train? 

•  In  what  level  of  detail  this  training  will  be  given? 

The  first  step  is  to  define  who  will  be  the  principal  users  of  the  system.  It  is 
important  to  provide  relevant  content  that  better  suits  the  expected  population  of 
users,  facilitating  acceptance  and  usability.  A  training  system  designed  for  young 
midshipmen  should  not  have  the  same  interface  as  one  designed  for  senior 
officers.  Exploring  the  motivational  factor  that  a  3D  simulation  game  can  bring  to 
the  training  environment  is  important.  Using  the  appropriate  set  of  stories  and 
symbols  will  trigger  more  enjoyment  and  satisfaction  in  that  specific  group  of 
users. 

The  next  step  is  to  elaborate  a  brief  description  of  each  mission  simulated 
and  trained  using  YPSim.  Navigation  and  shiphandling  are  two  vast  fields,  and 
one  could  imagine  an  almost  infinite  combination  of  parameters  and  tasks  when 
elaborating  a  mission  to  be  trained.  YPSim  has  a  very  specific  application  that  is 
bridging  the  knowledge  gap  between  classroom  and  hands-on  training  at  sea. 
There  is  no  need  to  design  YPSim  with  celestial  navigation  training  capabilities, 
for  example,  since  this  type  of  task  is  not  performed  aboard  of  the  YPs.  On  the 
other  hand,  tasks  such  as  Man  Overboard  (MOB)  and  Anchoring  are  essential 
and  extensively  trained  there.  The  identification  of  simulated  tasks  represents  an 
important  step  towards  a  good  design  of  YPSim. 

After  understanding  who  will  be  the  final  user  and  what  type  of  missions 
he/she  will  perform  using  YPSim,  a  complete  analysis  of  each  task  performed 
inside  these  missions  is  necessary.  Using  a  cognitive  task  analysis  methodology, 
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the  relevant  details  about  how  the  midshipmen  will  accomplish  his/her  goal  and 
the  resources  required  to  do  that  will  be  listed.  Knowing  that  the  system  needs  to 
be  designed  to  provide  MOB  recovery  types  of  missions  is  not  enough 
information.  Understanding  how  the  user  will  observe  the  apparent  wind 
information  from  the  sensors,  and  what  information  will  be  retrieved  to  indicate 
the  correct  timing  of  a  turning,  for  example,  is  also  very  important.  The  CTA  study 
will  gather  all  the  necessary  aspects  and  details  of  each  mission,  providing 
answers  to  the  third  question  and  defining  the  appropriate  level  of  detail  for  the 
system. 

A.  MISSION  DESCRIPTION 

The  YPSim’s  purpose  is  to  simulate,  in  a  3D  game  environment,  some  of 
the  basic  missions  performed  during  hands-on  training  exercises  aboard  naval 
academy  training  ships,  as  known  as  YPs.  Among  a  whole  set  of  missions 
usually  performed  aboard  the  YPs,  the  ones  that  have  greater  association  with 
classroom  instruction  are: 

•  Tactical  Maneuvering 

•  Underway  Replenishment 

•  Mooring/Unmooring 

•  Man  Overboard  (MOB) 

•  Basic  Navigation 

•  Anchoring 

The  above  missions  represent  the  most  important  set  of  tasks  to  simulate 
with  YPSim.  Other  types  of  missions  could  be  also  explored,  but  they  are 
considered  as  having  minor  effects  on  the  system’s  design,  and  could  be 
described  as  a  future  work. 

To  conduct  the  YP  operation,  each  midshipman  aboard  is  assigned  to  a 
specific  watch,  working  as  a  team.  Midshipmen,  when  assigned  to  a  watch,  are 
entrusted  with  the  safe  and  proper  operation  of  the  YP  (USNA,  1991.).  This 
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thesis  focuses  on  the  following  watches,  and  respective  responsibilities, 
conducted  by  midshipmen  at  the  YP’s  bridge: 

•  Officer  of  the  Deck  (OOD):  has  duties  of  supervision  of  the  ship’s 
operation  and  safe  navigation.  The  OOD  issues  necessary  orders 
to  helm  and  main  engines  control  to  maneuver  the  ship 

•  Junior  Officer  of  the  Deck  (JOOD):  OOD’s  assistant 

•  Quartermaster  of  the  Watch  (QOW):  assists  the  OOD  in  all 
navigation  matters,  maintaining  the  YP’s  navigational  track  and 
makes  timely  recommendations  to  the  OOD  concerning  the  YP’s 
position 

•  Helmsman:  stands  watch  at  the  YP’s  helm  steering  the  ship 

•  Lee  Helmsman:  stands  watch  at  the  YP’s  engine  order  telegraph 

•  Radar  Operator:  stands  watch  at  the  navigation  radar  (BNA’s  YP 
only)  reporting  bearing  and  distance  information  from  contacts  or 
landmarks  to  OOD 


Figure  7.  BNA's  YP  bridge  overview. 


A  brief  description  of  the  previously  listed  missions  is  given  below,  with 
respect  of  the  tasks  performed  by  the  midshipmen  on  watch  at  the  YP’s  bridge. 
The  BNA  YP’s  concept  of  operation  was  used  in  this  description,  assuming 
small — but  not  significant  in  the  scope  of  this  thesis — differences  to  the  USNA 
YP. 
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1. 


Tactical  Maneuvering 


During  this  type  of  mission,  the  OOD  is  responsible  for  maneuvering  the 
ship  to  a  given  position  relative  to  another  ship  in  a  formation,  designated  as  the 
guide  ship.  Any  ship  in  a  formation  can  be  assigned  as  the  guide.  The  OOD  will 
give  orders  for  engine  and  rudder  to  Helmsman  and  Lee  Helmsman, 
respectively,  in  order  to  change  the  ship’s  course  and  speed  to  reach  the  correct 
station  in  a  formation.  Once  on  station,  the  OOD’s  responsibility  becomes 
keeping  the  ship’s  position  relative  to  the  guide.  An  initial  procedure  preceding 
every  maneuver  is  interpreting  the  tactical  signal  transmitted  by  the  Officer  in 
Tactical  Command  (OTC).  The  orders  given  by  the  OTC,  telling  all  ships  to 
maneuver  and  assume  a  given  formation,  will  be  transmitted  using  tactical  signs. 
One  of  the  skills  trained  aboard  is  how  to  translate  the  tactical  signal  code  into 
meaningful  context.  The  competent  naval  shiphandler  must  know  the  contents  of 
these  publications  (the  tactical  signs  codes)  in  detail,  for  when  maneuvering  in 
formation,  there  is  rarely  time  to  look  up  the  answer  (Barber,  2005).  After 
transcribing  the  tactical  signal  into  plain  language,  the  OOD  will  be  able  to 
calculate  his/her  station  to  assume  in  the  formation,  course,  speed  and  time  to 
get  there.  Exercising  the  skills  of  interpreting  tactical  signals,  calculating  stations 
in  a  formation,  and  the  course  and  time  to  maneuver  are  complex  tasks  with 
which  a  midshipmen  will  require  time  to  become  comfortable.  The  YPs  are  a 
great  environment  in  which  to  conduct  this  kind  of  training,  but  the  amount  of 
midshipmen  to  be  trained  and  the  mistakes  that  usually  happen  make  it  an 
effective  training  for  only  a  few  students.  Using  a  game  simulation  like  YPSim, 
the  basic  skills  could  be  explored  individually  and  repeated  until  the  midshipman 
reaches  a  good  level  of  knowledge  before  going  to  the  real  YP  experience. 
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Figure  8. 

Typical  ship  formations  used  during  simple  tactical 
maneuvers  exercises  with  YPs. 

2.  Underway  Replenishment  (UNREP) 

UNREP  consists  of  a  maneuver  where  one  ship  transfers  supplies  to 
another,  while  steaming  on  parallel  courses  and  linked  up  alongside  (Barber, 
2005).  This  is  a  high-risk  maneuver  in  real  life  since  two  ships  must  be  in  close 
proximity  for  an  extended  time,  another  good  reason  to  be  trained  in  a  simulation. 
According  to  Barber’s  (2005)  “Naval  Shiphandler’s  Guide,”  the  UNREP  follows  an 
established  pattern  and  can  be  summarized  as  below: 

The  Officer  in  tactical  command  orders  a  course  and  speed 
(Romeo  Corpen  and  speed)  for  the  evolution.  The  delivering  ship 
comes  to  the  ordered  course  and  speed,  and  signals  on  which  side 
the  receiving  ship  should  approach.  The  entire  operation  is 
frequently  conducted  in  radio  silence,  using  flag  hoists.  The 
receiving  ship  moves  into  waiting  station  three  hundred  to  five 
hundred  yards  behind  the  delivering  ship,  offset  by  the  distance  it 
will  be  while  alongside,  usually  120  to  200  feet  (20  to  60  feet  for 
YPs,  according  USNA  (1991)),  depending  on  the  size  of  the 
receiving  ship.  When  the  delivering  ship  signals  her  readiness,  the 
receiving  ship  increases  speed  and  move  alongside.  She  then 
holds  the  position  alongside  while  the  transferring  rigs  are  passed 
and  tensioned,  the  transfers  are  completed,  and  the  transferring 
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rigs  returned  to  the  delivering  ship.  As  the  last  line  goes  clear  the 
receiving  ship  increases  speed  and  clears  out  ahead,  gradually 
increasing  separation  as  it  goes.  (Barber,  2005) 
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Figure  9.  Underway  replenishment  diagram.  Due  to  size 

proportions,  UNREP  distances  for  YPs  are  significantly 
smaller  than  the  used  in  the  fleet. 


The  UNREP  description  provided  by  Barber  apparently  seems  to  be  easy 
and  simple  and  in  fact,  it  is  not.  His  words  represent  a  simplification  and  a  model 
of  something  much  more  complex  when  executed.  Having  a  good  feeling  about 
the  ship’s  dynamics  and  effects  of  controlling  actions  (rudder  and  engines)  is 
crucial  to  a  good  performance  during  UNREP.  It  takes  time  to  gather  these  types 
of  skills,  and  confidence  comes  with  trial-and-error  experiences  over  much 
training.  Usually,  one  maneuver  like  this  will  consume  between  40  and  60 
minutes  in  a  expedite  mode  aboard  a  YP,  and  15  minutes  more  to  another 
execution.  Considering  that  each  daily  YP  training  section  is  approximately  four 
hours  long,  at  most,  three  midshipmen  could  be  trained  as  OOD  for  this  mission 
aboard  the  YP  per  day.  Using  a  game  simulation,  one  single  midshipman  could 
experiment  more  than  five  UNREP  maneuvers  in  the  same  time  length. 

3.  Mooring/Unmooring 

Defined  by  Grassi  (2000)  as  Pier  Side  Handling,  this  type  of  maneuver  is 
overviewed  as: 
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One  of  the  most  basic,  yet  extremely  critical,  evolutions  performed 
by  a  OOD.  It  is  also  one  of  the  most  rewarding  evolutions.  For  if  a 
OOD  can  smartly  and  safely  accomplish  a  pier  side  evolution,  it 
demonstrates  to  his  peers  how  good  of  a  ship  driver  he  or  she 
really  is.  Successfully  accomplishing  this  evolution,  however,  takes 
planning,  advance  preparation,  training,  and  the  teamwork  of 
everyone  involved.  (Dodge,  1981) 

Mooring  a  ship  simply  means  the  evolution  of  bringing  the  ship  alongside 
a  pier  using  rudder,  engine  and  mooring  lines.  Sometimes,  external  factors  will 
be  available  to  maneuver,  such  as  harbor  tugs.  Often,  environmental  conditions 
such  as  wind  and  sea  currents  will  be  present,  and  the  officer  needs  to  know  how 
to  play  with  these  factors  in  order  to  compensate  or  be  benefited  by  them. 
Unmooring  is  the  opposite;  using  the  same  resources  (rudder,  engines,  mooring 
lines,  tugs,  wind  and  current),  the  OOD  will  get  underway  from  a  pier.  In  a  regular 
situation,  a  fully  operational  YP  moors  and  unmoors  without  the  help  of  a  harbor 
tug.  The  crucial  element  of  this  task  is  understanding  how  to  use  all  the  available 
forces  in  order  to  move  the  ship  to  the  desired  position.  During 
mooring/unmooring,  ships  behave  differently  than  underway  due  to  the  lines 
connecting  with  the  pier.  This  factor  will  drastically  affect  a  ship’s  pivoting  point 
and  ability  to  move.  In  addition,  at  very  low  speeds,  dramatic  changes  happen  in 
the  way  rudder  forces,  wind  and  current  move  the  ship.  The  feeling  of  this 
dynamic  situation  is  hard  to  understand  in  a  classroom  instruction,  and  the  only 
chance  to  practice  this  concept  is  aboard.  Each  ship  has  its  own  characteristics; 
even  ships  of  the  same  class  act  differently  in  pier-side  shiphandling  evolutions. 
Basic  concepts,  on  the  other  hand,  can  be  easily  explored  using  a  game 
simulation  with  a  simplistic  physics  model,  as  is  the  case  of  YPSim. 
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4.  Man  Overboard  (MOB) 

There  are  many  standardized  maneuvers  to  accomplish  the  task  of 
recovering  a  person  from  the  water.  Each  one  of  them  has  its  pros  and  cons  but, 
in  general,  midshipmen  practice  two  of  them  onboard  the  YPs:  Williamson;  and 
Anderson. 

The  classic  man  overboard  recovery  maneuver  is  the  Williamson 
turn,  developed  during  World  War  II  by  Cdr.  John  A.  Williamson. 

The  goal  is  to  reverse  course  in  a  way  that  heads  a  vessel  back 
along  its  original  track.  When  properly  executed,  the  maneuver  will 
place  the  ship  in  her  own  wake  on  a  reciprocal  course.  The 
Williamson  turn  can  be  useful  for  recovery  of  a  person  whose 
position  is  known.  It  is  almost  imperative  if  the  person’s  position  is 
not  known.  The  classic  Williamson  turn  starts  with  full  rudder  to  the 
side  on  which  the  individual  went  over,  if  known.  Continue  with  full 
rudder  until  the  ship’s  heading  is  60  degrees  past  the  original 
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heading,  then  shift  to  opposite  full  rudder.  The  momentum  of  the 
turn  will  normally  carry  the  ship’s  heading  to  about  90  degrees  from 
the  initial  heading,  at  which  point  the  bow  starts  to  swing  in  the 
opposite  direction.  Continue  the  turn  with  full  rudder  to  steady  up  on 
the  reciprocal  of  the  original  track  about  one  turning  diameter  away 
from  the  point  at  which  the  turn  started.  (Barber,  2005) 

The  Anderson  turn  is  simpler,  and  it  is  used  when  the  person  is  in  sight, 
under  good  conditions  (Barber,  2005).  It  consists  of  a  full  rudder  continuous  turn 
with  a  full  engine  ahead  at  the  beginning,  and  decreasing  speed  from  the  half¬ 
way  to  the  end. 

Until  you  have  this  maneuver  accurately  calibrated  it  is  better  to 
take  off  speed  a  little  early  than  to  risk  overrunning  the  person  in 
the  water.  The  back  bell  (engines  backwards)  can  be  adjusted 
either  up  or  down  to  bring  the  ship  to  a  stop  at  the  chosen  pickup 
point.  This  will  normally  be  with  the  person  in  the  water  a  few  yards 
to  leeward  of  the  ship’s  bow.  The  ship  will  drift  downwind  at  a 
greater  rate  than  the  person  in  the  water.  Care  is  needed  to  keep 
the  person  being  recovered  forward  of  the  ship’s  intakes  and 
screws.  (Barber,  2005) 


Figure  11.  An  illustration  of  Anderson  and  Williamson  Man 

Overboard  maneuvers. 


The  OOD  also  executes  a  series  of  non-maneuverable  procedures  during 
a  MOB  mission,  such  as  giving  orders  to  hoist  Oscar  flag,  short  blasts  of  the 
ship’s  whistle  six  times,  checking  the  plotting  of  MOB  position  on  the  nautical 
chart  and  GPS,  and  giving  orders  to  throw  pyrotechnics  to  signal  the  individual’s 
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position,  among  others.  These  procedures  are  also  evaluated  aboard  in  training 
missions.  YPSim  could  easily  simulate  both  maneuver  and  administrative 
procedures  for  the  MOB  mission. 

5.  Basic  Navigation 

Missions  composed  of  moving,  in  a  safe  and  efficient  way,  the  ship  from 
point  A  to  point  B  are  defined  as  Basic  Navigation.  It  is  during  these  types  of 
missions  that  navigation  teams  get  team  training  on  many  navigational  topics — 
from  classroom  to  reality.  The  calculations  and  procedures  that  determine  a 
ship’s  position  are  not  part  of  the  OOD  role,  but  he/she  still  has  a  lot  to  learn  and 
train  for  during  Basic  Navigation.  The  OOD  will  be  responsible  to  evaluate  the 
information  provided  by  the  navigation  team,  keep  the  ship  safe  from  other 
contacts  and  hazards,  and  have  a  complete  picture  of  the  outside  world  in  his/her 
mind.  A  navigation  route  is  usually  planned  in  a  way  that  navigation  aids,  such  as 
buoys,  lighthouses,  and  landmarks  can  be  used  as  references  for  turning  points 
along  the  way.  Another  aspect  of  interest  explored  by  missions  of  this  sort  is  the 
alignment  of  conspicuous  points  on  the  horizon,  such  as  towers  and  lighthouses, 
which  give  the  OOD  an  exact  line  of  position  on  the  nautical  chart.  During 
navigation,  the  OOD  can  explore  the  use  of  the  radar,  experimenting  with 
controls  and  settings  while  obtaining  bearing  and  range  of  other  contacts  or 
hazards.  The  familiarity  with  all  these  basic  concepts  and  equipment  is 
something  that  takes  some  time  to  gather  during  the  hands-on  training  exercises, 
but  could  be  easily  simulated  in  a  virtual  environment  of  a  3D  game  such  as 
YPSim. 

6.  Anchoring 

Anchoring  is  a  precision  task  that  involves  a  basic  navigation  mission, 
ending  in  an  anchorage  position,  followed  by  a  set  of  standardized  procedures  to 
set  the  anchor.  The  objective  is  to  follow  a  pre-defined  route  that  ends  up  at  the 
anchoring  position,  usually  with  a  few  waypoints  before  getting  there.  The  OOD 
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is  responsible  for  (1)  giving  the  appropriate  orders  of  rudder  and  engine  that  will 
keep  the  ship  close  to  the  planned  track,  (2)  execute  turns  at  the  waypoints,  (3) 
controlling  effects  caused  by  wind  and  sea  current,  and  (4)  setting  anchor  at  the 
right  position.  If  a  desired  ETA  (Estimated  Time  of  Arrival)  is  required,  OOD  will 
be  responsible  for  controlling  the  YP’s  speed  and  set  anchor  at  a  specific  time. 
The  navigation  team  is,  again,  responsible  for  determining  the  ship’s  position  and 
providing  suggestions  on  the  course  and  speed  to  the  OOD,  who  will  judge 
whether  to  accept  it  or  not.  Before  reaching  the  anchorage  position,  OOD 
releases  some  important  information  to  the  Boatswain  at  the  forecastle,  providing 
depth  at  anchorage,  scope  of  chain  to  pay  and  the  nature  of  the  seabed.  During 
the  anchoring,  the  Boatswain  stays  at  the  forecastle  with  his  team  operating  the 
anchor  gear  and  reporting  anchor  status  to  the  OOD.  On  reaching  the  anchoring 
position,  the  OOD  stops  the  ship,  drops  the  anchor  and  moves  the  ship  in 
reverse  until  it  is  secured  and  will  no  longer  move.  Knowing  that  an  anchor  is 
properly  set  on  the  seabed  and  securely  holding  the  ship  is  fundamental  to 
assess  whether  the  maneuver  is  over.  Instruments  and  environment  will  provide 
cues  for  the  OOD  to  evaluate  as  to  whether  the  ship  is  anchored  or  not,  such  as 
relative  movements  of  fixed  land  points  and  water  flow  alongside  the  ship. 
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Figure  12.  A  simplified  representation  of  the  Anchoring  maneuver. 
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B.  COGNITIVE  TASK  ANALYSIS  (CTA) 


According  to  Crandall  (2006),  CTA  is  a  family  of  methods  used  to  study 
and  describe  reasoning  and  knowledge,  applied  by  trainers  and  instructional 
designers  to  identify  processes  to  be  trained  and  how  to  best  train  them.  CTA 
purpose  can  also  be  represented  by  modeling  the  actions,  knowledge  and 
cognitive  process  used  by  an  individual  performing  a  task  (Jonassen,  1999). 

Although  CTA  is  not  the  main  research  focus  of  this  thesis,  it  represents 
an  important  tool  when  designing  requirements  for  YPSim.  Identifying  the  most 
important  tasks  to  simulate,  the  critical  cues  necessary  to  provide,  the  actions 
required,  and  the  set  of  skills  expected  to  be  learned  while  playing  the  game  is 
fundamental.  A  good  example  is  during  a  Man  Overboard  mission,  when  the 
OOD  uses  the  ship’s  wake  as  a  very  important  visual  cue  to  identify  how  fast  the 
ship  is  turning  and  assess  whether  any  controlling  action  is  required.  If  the  ship’s 
wake  is  not  presented  in  the  simulation,  this  cue  will  be  omitted  and  the 
instructional  potential  of  the  game  therefore  affected.  This  type  of  understanding 
about  the  user  playing  his/her  role  in  the  system  is  absolutely  essential  to  a  good 
system  design.  The  use  of  this  methodology  leads  to  the  establishment  of 
learning  objectives  and  performance  metrics  used  in  a  feedback  and  scoring 
component  of  the  system.  It  is  not  only  important  to  enumerate  the  system’s 
capabilities  but  also  making  clear  what  it  is  not  intended  to  train.  Trying  to  use  a 
game  simulator  to  train  complex  missions  or  using  it  as  a  realistic  physics  model 
of  the  YP  could  lead  to  a  potential  negative  training  transfer. 

For  the  scope  of  this  thesis,  only  two  missions  among  the  six  previously 
described  will  be  analyzed  in  detail:  (1)  Anchoring,  and  (2)  Man  Overboard. 
These  two  missions  were  selected  because  of  their  generalizable  set  of 
requirements,  hoping  to  provide  a  solid  framework  for  future  development  of  the 
remaining  four  missions. 

This  CTA  is  focused  only  in  tasks  performed  by  midshipmen  playing  the 
OOD  role  aboard  the  YP.  The  OOD  is  the  duty  of  higher  responsibility  at  the  YP’s 
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bridge,  and  is  usually  carried  out  by  a  senior  midshipman.  YPSim  is  designed  for 
senior  midshipmen  to  serve  as  the  primary  users  playing  the  OOD  role  in  the 
simulation.  Adopting  a  three-step  approach  for  studying  the  cognitive  process  of 
the  two  selected  missions,  Man  Overboard  and  Anchoring,  the  CTA  in  this  work 
is  presented  in  the  following  sequence: 

•  Conduct  a  Hierarchical  Task  Analysis  (HTA) 

•  Elaborate  a  Critical  Cues  Inventory  (CCI) 

•  Identify  performance  metrics 

The  next  sections  describe  the  steps  above,  using  Observations  and 
Document  Analysis  techniques  for  collection  of  preliminary  knowledge  (Clark, 
2008).  The  author  used  an  adaptation  of  standard  procedures  listed  on  Barber 
(2005),  Bowditch  (2002),  Crenshaw  (1975),  Hooyer  (2004)  and  Miguens  (n.d.), 
all  reference  manuals  for  shiphandling  at  USNA  or  BNA,  as  source 
documentation.  All  procedures  were  adapted  to  the  BNA  YP’s  operation,  which 
can  differ  in  some  small  aspects  from  the  USNA  reality.  The  author’s 
observations  of  tasks  conducted  in  2008  aboard  a  BNA’s  YP  were  also  used  as  a 
source  of  preliminary  knowledge.  Initial  versions  of  HTA  and  CCI  were 
constructed  from  the  list  of  procedures  and  observations  and  submitted  for 
review  to  three  former  YP  instructors  at  the  BNA.  The  results  presented  here  in 
this  thesis  are  previously  reviewed  versions. 

1.  Hierarchical  Task  Analysis  (HTA) 

Details  and  hierarchy  of  the  tasks  performed  by  the  OOD,  during  the  Man 
Overboard  and  Anchoring  exercises  aboard  the  YPs,  are  captured  in  this  section. 
To  offer  a  better  understanding  of  the  tasks  hierarchy  and  chronological 
sequence  of  actions,  we  build  a  summary  diagram.  The  detailed  description  of 
each  task  node  in  the  hierarchical  diagram  is  listed  in  a  table  format,  presented  in 
Appendices  H  and  I.  The  task’s  details  contain  valuable  information  about  some 
basic  cognitive  processing,  sensorial  perception  and  interactions  performed  by 
the  OOD. 
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a. 


HTA  for  Man  Overboard  (Anderson  Turn)  Task 


The  tasks  conducted  by  the  OOD  on  a  Man  Overboard  mission 
aboard  the  YP,  as  described  in  Section  A.4  of  this  chapter,  are  summarized  in 
Figure  13.  Detailed  information  of  each  task  are  presented  in  Table  13  (Appendix 
H). 


Figure  13.  Hierarchical  diagram  for  the  Man  Overboard  task. 


b.  HTA  for  Anchoring  Task 

The  tasks  conducted  by  the  OOD  on  a  Anchoring  mission  aboard 
the  YP,  as  described  in  Section  A.5  of  this  chapter,  are  summarized  in  Figure  14. 
Detailed  information  of  each  task  are  presented  in  Table  14  (Appendix  I). 
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Figure  14.  Hierarchical  diagram  for  the  Anchoring  task. 


2.  Critical  Cue  Inventory  (CCI) 

Defined  as  a  collection  of  informational  and  perceptual  cues  that  are 
present  when  executing  a  given  protocol  (Klein,  1998),  the  CCI  is  an  important 
tool  for  the  design  of  YPSim.  Once  the  identification  of  the  CCI  is  done,  the 
designer  will  have  a  complete  list  of  the  information  required  by  the  user  during 
the  simulation.  Grassi  (2000)  successfully  used  this  technique  in  his  study  for  a 
“Virtual  Environment  Pier  Side  Shiphandling  Simulator.”  This  thesis  adopts  a 
CCI’s  format  similar  to  the  one  used  by  Grassi  (2000),  with  perceptual  cues  listed 
on  the  lefthand  side  and  their  descriptions  on  the  righthand  side.  Each  CCI  table 
refers  to  a  specific  decision  or  action  step  on  the  hierarchical  diagram  for  both 
MOB  and  Anchoring  tasks.  At  each  of  these  steps,  perceptual  cues  and 
information  were  analyzed  and  described,  showing  how  and  where  OOD  acquire 
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them,  and  how  they  are  used  in  the  maneuver  process.  The  CCIs  were  divided 
according  to  each  specific  mission  explored  in  this  work,  i.e. ,  MOB  and 
Anchoring. 


a.  CCI  for  Man  Overboard  Task 


Table  1 .  Critical  Cue  Inventory  for  checking  surroundings  before  turning. 


Critical  Cue  Inventory  for: 

Step:  1.1.1  Check  Surroundings  for  Contacts  or  Hazards 

Cue 

Description 

Visual  at  the  bridge 
wing 

OOD  goes  to  the  bridge  wing  of  the  side  of  the  intended  turn  (port 
or  starboard)  and  visually  observes  the  surroundings  at  close 
distance.  Any  contact,  such  as  ships  or  boats,  at  that  side  and  at 
close  range  should  be  visible,  assuming  a  good  visibility  condition 
for  this  type  of  maneuver  (Anderson  Turn).  OOD  also  looks  for 
close  distance  navigation  hazards  such  as  buoys  or  land 
obstructions  that  could  interfere  while  turning. 

Table  2.  Critical  Cue  Inventory  for  checking  MOB’s  bearing  and  range. 


Critical  Cue  Inventory  for: 

Step:  1 .2  Check  MOB  bearing  and  range 

Cue 

Description 

Visual  at  the  bridge 
wing 

OOD  stays  at  the  bridge  wing  (of  the  same  side  of  the  turn)  during 
the  maneuver,  observing  the  MOB.  Binoculars  may  be  used  to 
facilitate  sighting.  Smoke  sign  and  lifebuoy  will  help  to  spot  MOB’s 
position.  Bearings  can  be  read  on  the  gyro  repeater  located  at 
both  bridge  wings  (port/stbd.).  MOB  distance  is  more  difficult  to 
precise,  however  the  relative  notion  of  how  fast  the  ship  is  getting 
close  to  the  MOB  is  key.  The  rate  of  change  of  bearing  marks  is 
also  important  to  guide  OOD  during  the  “final  approach”  step  of 
the  maneuver.  MOB’s  rate  of  change  on  bearing  and  range 
represent  the  system  feedback  for  OOD’s  changes  on  course  and 
engines  RPM. 

Ouartermaster  of  the 
watch  report 

Quartermaster  of  the  watch  verbally  reports  MOB  bearing  and 
range  from  GPS.  OOD  can  dismiss  this  information  if  MOB  is 
sighted,  avoiding  excess  of  noise  during  the  maneuver. 
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Table  3.  Critical  Cue  Inventory  for  checking  ship’s  status. 


Critical  Cue  Inventory  for: 

Step:  1.2 

Check  Ship’s  Status 

Cue 

Description 

Sound  of  engines 

Used  by  OOD  to  audibly  detect  engine  changing  speed.  At  the 
bridge  wing,  this  sound  is  noticeable  and  provides  a  good 
feedback  to  OOD  if  his/her  engine  orders  were  executed. 

Gyro  Repeater 

Used  by  OOD  to  check  the  ship’s  heading,  MOB’s  bearing  and 
rate  of  swing  of  the  ship.  They  are  located  at  each  bridge  wing. 

Engine  Control  Levers 

Used  by  OOD  to  visually  check  the  RPM  status  of  both  engines 
(port/stbd.).  The  engine  control  is  located  inside  the  bridge  and 
operated  by  the  Lee-helmsman.  From  each  bridge  wing,  the 
OOD  can  quickly  check  the  levers  position  of  both  engines, 
providing  an  important  cue  of  engine  status  without  asking  Lee- 
helmsman.  This  resource  is  key  since  OOD  can  easily  forget 
his/her  last  engine  orders  during  the  maneuver. 

Rate  of  swing  of  ship’s 
bow 

Used  by  OOD  to  visually  check  the  ship’s  response  to  his/her 
rudder  orders.  A  good  feedback  to  check  if  the  rudder  order 
was  accomplished  as  desired.  This  cue  is  also  key  to  OOD’s 
evaluation  for  following  changes  in  rudder. 

Ship’s  wake 

Used  by  OOD  to  visually  detect  engine  changing  speed.  At  the 
bridge  wing,  OOD  can  check  ship’s  wake  after  giving  any 
engine  order  and  observe  for  any  change  as  a  feedback. 

Relative  motion  of 
MOB 

Both  bearing  and  range  of  MOB  are  used  by  OOD  to  evaluate 
ship’s  movement  towards  the  MOB  itself.  The  MOB’s  relative 
motion  guides  OOD  at  the  final  approach  working  as  a  control 
point.  Every  maneuver  decision  made  by  OOD  relies  on  this 
cue. 

Helmsman  and  Lee- 

helmsman 

Acknowledgement 

Used  by  OOD  to  check  if  engine  and  rudder  orders  were 
acknowledge.  After  every  rudder  or  engine  order,  Helmsman 
and  Lee-helmsman,  respectively,  verbally  respond  in  a 
standard  manner. 
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Table  4.  Critical  Cue  Inventory  for  checking  environmental  conditions. 


Critical  Cue  Inventory  for: 

Step:  1.3  Check 

Environmental  Conditions 

Cue 

Description 

State  of  water 

Used  by  OOD  to  estimate  the  direction  and  magnitude  of  the  wind. 
The  OOD  is  looking  at  the  white  caps  or  ripples  in  the  water  created 
by  the  wind  (Grassi,  2000).  The  state  of  water  will  determine  the 
amount  of  variation  on  course  and  speed  ship  will  present  at  the  “final 
approach”  step.  With  calm  seas,  this  variation  caused  by  swell  is  little, 
increasing  as  the  sea  state  gets  higher. 

Wind  bird 

Used  by  OOD  to  measure  the  magnitude  and  direction  of  relative 
wind.  At  the  bridge  wing,  OOD  has  a  good  sight  of  the  wind  bird, 
located  at  the  ship’s  mast.  This  cue  is  one  of  the  most  important  to 
determine  which  side  (port/stbd.)  will  be  used  to  recover  the  MOB 
(should  be  placed  at  leeward). 

Smoke  sign 

Used  by  OOD  to  estimate  the  true  magnitude  and  direction  of  wind. 

Pennants/Flags 

Used  by  OOD  to  estimate  the  relative  magnitude  and  direction  of 
wind. 

Water  temperature 

table 

Used  by  Quartermaster  of  the  watch  to  retrieve  the  water  temperature 
and  inform  OOD.  OOD  uses  the  water  temperature  to  estimate  the 
survival  time  of  MOB. 

Table  5.  Critical  Cue  Inventory  for  administrative  procedures. 


Critical  Cue  Inventory  for: 

Step:  1.4 

Administrative  Procedures  (feedback  of  the  actions  taken) 

Cue 

Description 

MOB  symbol 

Marked  on  the  nautical  chart,  and/or  GPS  plotter,  to  indicate  MOB’s 
geographic  position.  Used  by  Quartermaster  of  the  Watch  to  inform 
MOB’s  bearing  and  range  to  OOD.  OOD  can  also  obtain  this 
information  by  directly  watching  MOB’s  position  on  chart/GPS. 

Six  Short  Blasts 

The  sound  of  the  ship’s  whistle  is  used  to  provide  an  auditory 
communication  with  ships  in  the  vicinity.  The  six  short  blasts  is  a 
standard  signal  that  indicates  an  emergency,  in  this  case  the  MOB. 
This  cue  indicates  the  accomplishment  of  OOD’s  order  (step  1 .4.2). 

Smoke  Sign 

OOD  sees  it  floating  in  a  position  assumed  to  be  close  to  the  MOB, 
indicating  that  his  order  (step  1.4.3)  was  accomplished.  The  smoke 
sign  is  more  helpful  than  lifebuoy  to  MOB’s  sighting,  and  will  provide 
an  extra  visual  cues  for  wind  direction. 

OSCAR  Flag 

Used  to  visually  communicate  this  emergency  (MOB)  to  other  ships  at 
visual  range.  When  hoisted  at  the  YP’s  mast,  indicates  that  OOD’s 
order  (step  1.4.4)  was  accomplished.  The  OSCAR  flag  can  be  used 
as  a  secondary  means  of  assessing  relative  wind  speed  and  direction 
(the  primary  source  in  this  case  is  the  wind  bird). 
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b. 


CCI  for  Anchoring  Task 


Table  6.  Critical  Cue  Inventory  for  administrative  procedures. 


Critical  Cue  Inventory  for: 

Step:  2.1  Pre-acl 

:ion  procedures  (briefing) 

Cue 

Description 

Nautical  Chart 

Used  by  OOD  to  create  a  mental  picture  of  the  maneuver, 
including  the  entire  navigation  route  up  to  the  anchorage, 
possible  hazards,  expected  landmarks  and  anchorage  features. 
Important  anchorage  features  are  depth,  nature  of  seabed  and 
shelter  level  from  winds  and  strong  currents. 

Tide  Table 

Used  by  OOD  to  estimate  the  tide  level  and  current  at  the 
anchorage.  The  tide  level  is  used  to  calculate  the  appropriate 
scope  of  chain  while  the  current  is  one  of  the  important  forces 
acting  on  the  ship  during  the  maneuver. 

Weather  Forecast 

Used  by  OOD  to  estimate  the  meteorological  conditions  at  the 
anchorage.  Wind  and  swell,  are  important  factors  in  mental 
picture  of  the  maneuver  the  OOD  has  to  elaborate,  since  they 
could  affect  ship’s  behavior  especially  at  low  speed.  The 
meteorological  conditions  at  the  time  of  the  maneuver  are 
relevant  however,  the  forecast  of  these  factors  are  also 
important  to  set  the  best  anchorage  and  the  correct  scope  of 
chain.  When  a  bad  weather  is  forecasted,  very  often  the  wind 
will  come  from  a  different  direction  and  stronger  intensity.  This 
predicted  change  on  the  wind  would  lead  to  an  sheltered 
anchorage  that  is  different  than  the  current  situation  solution. 
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Table  7.  Critical  Cue  Inventory  for  Navigation. 


Critical  Cue  Inventory  for: 

Step:  2.2  Navigation  to  Anchorage 

Cue 

Description 

Navigation  Report 

Standardized  set  of  information  regarding  ship’s  navigation  that  is 
periodically  (usually  every  three  minutes)  reported  to  OOD.  Navigator 
is  responsible  for  providing  such  report  and  verbally  transmits  to 
OOD.  Used  to  create  a  mental  picture  of  the  current  status  of  the 
ship’s  position  in  relation  to  navigation  route.  The  reports  contains 
information  such  as  bearing,  range  and  time  to  the  next  waypoint, 
offset  to  the  route,  suggestion  of  course  and  speed  to  keep  ship  on 
track,  course  after  next  waypoint,  depth  registered  at  the  fathometer, 
range  to  the  anchorage  and  calculated  current  affecting  ship. 

Visual  of  Surface 
Contacts 

During  every  navigation  OOD  must  keep  track  of  potential  hazards 
that  could  affect  ship’s  safety  while  underway.  One  of  the  most 
important  category  of  hazards  are  surface  contacts  navigating  or  not 
close  to  ship’s  route.  OOD  frequently  scans  the  horizon  for  contacts 
and  keep  a  mental  picture  of  the  ones  that  can  affect  his  decisions 
about  course  and  speed.  Binoculars  are  an  important  artifact  to 
improve  OOD’s  situational  awareness  and  evaluate  contacts  relative 
movement. 

Visual  of  Landmarks 

Used  to  reinforce  OOD’s  mental  picture  of  the  nautical  chart 
representation  of  the  environment.  Landmarks  are  used  as  references 
during  the  navigation  and,  more  especially,  when  approaching  the 
anchorage  as  a  head  mark. 

Radar 

Used  to  determine  range  and  bearing  of  landmarks  used  as 
navigation  references.  Often  used  to  estimate  the  relative  movement 
of  surface  contacts,  as  well. 

Anemometer 

Used  to  evaluate  direction  and  magnitude  of  relative  wind  that  could 
potentially  affect  ship’s  Course  Over  Ground  (COG).  The 
anemometer  panel  is  located  inside  the  navigation  bridge. 

Fathometer 

Used  to  evaluate  current  depth  at  ship’s  position.  Depth  is  periodically 
provided  by  Navigator  in  his/her  report,  however  this  information  is 
always  available  by  OOD’s  request. 

Gyro  Repeater 

Used  to  obtain  bearings  of  landmarks,  surface  contacts  and  check 
clearance  in  a  given  direction.  There  is  one  gyro  repeater  located  in 
each  bridge  wing. 

GPS 

Used  to  obtain  ship’s  speed  and  course  over  the  ground.  When 
navigation  route  is  set,  can  be  used  to  retrieve  bearing,  distance, 
track  offset  and  ETA  to  the  waypoints  on  the  route.  The  GPS  is 
located  inside  the  bridge  and  OOD  is  not  always  allowed  to  use  it. 

Speedometer 

Used  to  read  the  ship’s  speed  over  the  water.  Navigator  uses  this 
information  in  his  current  calculation.  OOD  can  use  it  all  the  times  to 
check  speed  and  evaluate  his  current  engine  orders. 
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Table  8.  Critical  Cue  Inventory  for  Drop  and  Set  Anchor. 


Critical  Cue  Inventory  for: 

Steps:  2.2.7  &  2.2.8 

Drop  and  Set  Anchor 

Cue 

Description 

Boatswain  Report 

The  Boatswain  stays  at  the  forecastle  observing  the  anchor 
and  chain  at  close  distance  after  dropping  it.  Information  about 
the  anchor  conditions  (holding  or  dragging,  how  the  anchor  is 
tending  -  "9  o'clock,"  "12  o'clock,"  number  of  shots  of  chain, 
etc.),  and  what  sort  of  tension  is  on  the  anchor  chain  will  be 
vital  to  OOD  properly  set  the  anchor  (USNA,  1991). 

Visual  of  Landmarks 

At  very  close  distance  to  the  anchorage,  OOD  needs  some 
constant  reference  to  assess  ship’s  position.  Navigator  can 
only  provide  reports  in  some  time  steps  that  can  be  too  long  at 
the  final  approach.  Knowing  that  some  landmark  or  navigation 
aid  should  be  at  a  given  bearing  at  the  anchorage  can 
represent  an  important  reference  to  OOD  assess  ship’s 
position  relative  to  his/her  goal.  Observations  of  two  objects 
abeam  and  aligned  at  different  ranges  can  provide  OOD  a 
reliable  source  for  ship’s  movement  when  stopping  for  dropping 
the  anchor. 

Radar 

At  the  final  approach  can  be  used  by  OOD  to  measure  distance 
to  landmarks  ahead  the  ship.  If  the  distance  to  this  landmark  is 
known  at  the  anchorage  and  ship  is  on  track,  then  OOD  will 
have  a  reliable  distance  to  his/her  goal. 

Anchor  Buoy 

A  small  buoy  is  attached  to  the  anchor  with  a  cable  length 
proportional  to  the  anchorage  depth.  This  buoy  is  a  valuable 
reference  for  OOD’s  mental  picture  of  the  underwater  gear 
(anchor  and  chain).  The  OOD  needs  to  pull  the  chain,  usually 
moving  the  ship  astern  at  low  speed,  in  order  to  properly  setting 
the  anchor.  Having  a  constant  visualization  of  anchor’s  position 
will  lead  to  a  better  maneuver. 

Other  ship’s  at  anchor 
in  the  vicinity 

Used  to  estimate  the  resulting  forces  of  wind  and  current  at  the 
anchorage  area.  Ships,  boats  and  other  floating  objects  at 
anchor  tend  to  align  to  the  strongest  force  being  applied  (wind 
or  current).  This  information  is  key  to  OOD  predict  the  best 
direction  to  pull  the  anchor  and  easily  set  it. 

C.  PERFORMANCE  METRICS 

Instructors  are  constantly  evaluating  midshipmen  performance,  while 
training  aboard  the  YP.  The  OOD  midshipmen  is  the  most  important  duty  at  the 
YP’s  bridge,  and  therefore  the  most  demanding  regarding  performance 
evaluation.  There  are  many  aspects  of  a  midshipman’s  action,  while  playing  the 
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role  of  OOD,  which  require  the  instructor’s  attention.  From  leadership  to  safety 
procedures,  the  OOD’s  actions  are  always  subject  to  evaluation.  This  work  is 
focused  on  the  OOD’s  shiphandling  skills  only;  Some  performance  metrics  for 
each  one  of  the  studied  missions,  Man  Overboard  and  Anchoring,  is  described 
below.  A  broad  view  of  how  midshipmen  are  evaluated  as  the  OOD  aboard  the 
Brazilian  Naval  Academy’s  YP  will  help  the  design  of  the  system,  concerning 
performance  measurement  and  instructional  feedback.  These  metrics  will  vary 
from  one  naval  academy  to  another,  and  sometimes  between  YPs  of  the  same 
institution,  depending  on  instructor’s  style. 

1.  Evaluating  OOD’s  Performance:  Anchoring 

Some  generic  performance  metrics  for  OOD  executing  an  Anchorage 
mission  are  described  in  Table  9. 


Table  9.  OOD’s  performance  evaluation  for  Anchoring  mission. 


Indicator 

Description 

Metric 

T rack  Offset 

Overall  evaluation  of  ship’s  offset  from  the  navigation 
route  up  to  the  anchorage. 

Distance 

(yards) 

ETA  Offset 

Evaluating  whether  or  not  the  ship  arrives  early  or  late 
to  each  waypoint. 

Time 

(seconds) 

Frequency  of 
Changes 

Evaluating  how  frequently  OOD  issued  rudder  or 
engine  orders.  An  experienced  OOD  usually  issue 
fewer  commands  than  a  novice.  That’s  not  always 
true  since  fewer  commands  could  be  a  product  of  a 
poor  decision  process. 

Counts  per 
mission 

Time  to  Set 
Anchor 

Time  between  dropping  and  properly  setting  the 
anchor. 

Time 

(seconds) 

Anchorage 

Offset 

Distance  between  the  position  anchor  was  set  and  the 
intended  Anchorage. 

Distance 

(yards) 

Selection  of 

Scope  of  Chain 

Evaluating  how  well  OOD  selected  the  appropriate 
scope  of  chain  to  use.  This  value  is  a  function  of 
anchorage  depth,  tide  level,  nature  of  seabed,  wind 
and  current. 

Length 

(shots  of 

chain,  one 
shot  =  90 

feet) 

Evaluation  of 

Evaluating  how  well  OOD  evaluated  the  anchorage 

Subjective 
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Indicator 

Description 

Metric 

Anchorage 

Shelter 

regarding  its  shelter  level  to  expected  wind,  swell  and 
current. 

Safety 

Evaluating  how  well  OOD’s  actions  led  to  a  safe 
navigation.  Can  be  inversely  proportional  to  the 
number  of  times  safety  rules  were  broken. 

Subjective 

Speed 

Evaluating  how  well  OOD  followed  the  speed 
reductions  schedule  along  the  route. 

Subjective 

Engine 

Overload 

Evaluating  the  number  of  times  OOD  put  engines 
under  overload  conditions. 

Counts  per 
mission 

Information 

Flow 

Evaluating  how  well  OOD  communicated  with 
Boatswain  (reporting  range  to  anchorage),  Navigator, 
Helmsman  and  Lee-helmsman. 

Subjective 

Administrative 

Procedures 

Evaluate  if  OOD  accomplish  a  series  of  administrative 
procedures  listed  on  Step  2.6.1  of  Table  2. 

Yes/No 

2.  Evaluating  OOD’s  Performance:  Man  Overboard  (MOB)  Using 
Anderson  Turn 

Some  generic  performance  metrics  for  OOD  executing  a  MOB  mission  are 
described  in  Table  10. 


Table  10.  OOD’s  performance  evaluation  for  MOB  mission  (Anderson  turn). 


Indicator 

Description 

Metric 

Frequency  of 
Changes 

Evaluating  how  frequently  OOD  issued  rudder  or 
engine  orders.  An  experienced  OOD  usually  issue 
fewer  commands  than  a  novice.  That’s  not  always 
true  since  fewer  commands  could  be  a  product  of  a 
poor  decision  process. 

Counts  per 
mission 

Time  to 

Recovery 

Time  between  MOB  is  reported  and  recovery. 

Time 

(seconds) 

Recovery 

Distance 

Evaluating  how  close  to  the  recovery  station  the  MOB 
was  positioned  at  the  end  of  maneuver. 

Distance 

(yards) 

Recovery  Side 

Evaluating  OOD’s  decision  about  the  recovery  side 
(port/stbd .).  The  MOB  should  be  placed  at  leeward  at 
the  end  of  maneuver. 

Yes/No 

Safety 

Evaluating  how  well  OOD’s  actions  led  to  a  safe 
recovery,  avoiding  placing  MOB  at  risk. 

Subjective 

Initial  Turn 

Evaluating  if  OOD  was  able  to  move  the  stern  away 

Yes/No 
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Indicator 

Description 

Metric 

from  MOB  during  the  initial  turn. 

Engine  and 

Rudder 

Evaluating  how  well  OOD  followed  the  procedures  to 
Anderson  turn,  regarding  rudder  and  engines  orders. 

Subjective 

Engine 

Overload 

Evaluating  the  number  of  times  OOD  put  engines 
under  overload  conditions. 

Counts  per 
mission 

Information 

Flow 

Evaluating  how  well  OOD  communicated  with 
Boatswain,  Quartermaster  of  the  watch,  Helmsman 
and  Lee-helmsman. 

Subjective 

Administrative 

Procedures 

Evaluate  if  OOD  accomplish  a  series  of  administrative 
procedures  listed  on  Step  1.4  of  Table  1. 

Yes/No 
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IV.  REQUIREMENTS  ANALYSIS 


A.  OVERVIEW 

The  Requirement  Analysis  process  is  a  collection  of  customer  needs  and 
objectives  in  the  context  of  intended  use,  environment,  and  systems 
characteristics  that  will  determine  requirements  for  system  functions  (UAD, 
2001).  Using  the  Requirement  Analysis  process  prior  to  the  design  phase  in  this 
research  resulted  in  a  better  understanding  of  YPSim  as  a  training  system,  its 
functions  and  constraints. 

The  framework  adopted  in  this  chapter  is  similar  to  that  used  by 
McDonough  and  Strom  (McDonough,  2005)  and  Brannon  and  Villandre 
(Brannon,  2002)  in  their  designs  of  Forward  Observer  PC  Simulator  (FOPCSIM) 
1  and  2,  respectively. 

1.  Purpose 

YPSim  is  a  game-based  simulator  primarily  designed  to  provide  a  virtual 
environment  representation  of  navigation  and  shiphandling  tasks  performed  by 
the  Officer  of  the  Deck  (OOD)  aboard  a  naval  academy’s  Yard  Patrol  craft  (YP). 
The  knowledge  gap  between  classroom  instruction  and  hands-on  training  aboard 
the  YPs  is  expected  to  be  reduced  by  the  use  of  this  game  simulator,  improving 
training  outcome  at  sea. 

As  secondary  applications,  YPSim  can  be  used  as  part  task  simulator  for 
navigation  and  shiphandling  courses  in  naval  academies,  as  an  instructional 
resource  for  classroom  purposes,  and  as  a  motivational  tool  for  naval  academy 
students. 


43 


2. 


Users  Demographics 


The  primary  user  population  of  YPSim  is  represented  by  naval  academy 
senior  midshipmen,  male  or  female,  ranging  in  age  from  20  to  25  years,  with 
previous  basic  classroom  instruction  in  navigation  and  shiphandling. 

YPSim’s  secondary  users  are  naval  academy  midshipmen  from  other 
grades,  male  or  female,  ranging  in  age  from  17  to  24.  Naval  academy  instructors 
of  navigation  and  shiphandling  courses,  with  profound  knowledge  of  navigation 
and  shiphandling,  ranging  in  age  from  30  to  65,  are  also  considered  secondary 
users  of  the  system. 

3.  User  Environment 

YPSim  will  be  flexible  enough  to  use  as  stand-alone  software  in  a  laptop 
computer,  or  configured  using  multiscreen  and  network  capabilities  in  a  lab 
environment  for  instruction.  Naval  academy  midshipmen  can  use  YPSim  without 
an  instructor’s  supervision,  referring  to  the  simulator’s  scoring  system  for  a 
performance  assessment.  In  a  lab  configuration,  YPSim  can  be  set  to  use  a  flight 
yoke  type  of  controller,  allowing  three  midshipmen  to  play  different  roles  (OOD, 
Helmsman  and  Lee  Helmsman)  in  the  simulation,  under  an  instructor’s  guidance. 
For  classroom  use,  the  instructor  could  execute  YPSim  using  a  wall  projector  in 
order  to  demonstrate  basic  concepts  of  the  six  missions  described  in  Chapter  III. 

4.  Technology  and  Dependencies 

YPSim  is  a  low-cost  game  simulation  developed  in  C++,  using  Delta3D, 
an  open  source  game  and  simulation  engine  maintained  at  the  Naval 
Postgraduate  School  in  the  Modeling  and  Simulation  (MOVES)  Institute.  The 
following  Delta3D’s  external  dependencies  are  required  to  run  YPSim: 

•  OpenGL,  for  3D  rendering 

•  OpenSceneGraph  (OSG),  for  scene  graph  organization 

•  OpenAL,  for  audio 
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•  Open  Dynamics  Engine  (ODE),  for  physics 

•  Crazy  Eddie’s  Graphical  User  Interface  (CEGUI),  for  Graphical 
User  Interface  (GUI) 

•  Game  Networking  Engine  (GNE),  for  networking 

B.  SUMMARY  OF  CAPABILITIES  AND  LIMITATIONS 

1.  Capabilities 

A  list  of  desired  capabilities  and  its  correspondent  benefits  to  YPSim  are 
summarized  in  Table  1 1 . 


Table  1 1 .  Summary  of  Capabilities  of  YPSim. 


Supporting  Feature 

Benefit 

Use  of  environmental  conditions  on  the 

scenario  settings 

Increase  immersion  and  training 

scenarios 

YP’s  physical  model  with  good  realism 

and  real  time  performance 

Increase  immersion  and  training 

3D  Model  of  the  YP’s  area  of  operation 

Increase  immersion 

Multiple  scenarios,  at  least  one  for 

each  mission  described  on  Chapter  III. 

Cover  the  full  range  of  training 

scenarios  aboard  the  YP 

Multiple  screens  setup  option 

Provide  flexibility  for  different 

configuration  environments 

Multiple  input  devices 

Provide  flexibility  for  different 

configuration  environments 

Multiple  views  option 

Increase  training  visualization 

Ocean  model 

Increase  immersion  and  refine  YP’s 

physical  model 
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Supporting  Feature 

Benefit 

Performance  Evaluation 

Provide  user  feedback 

Network 

Increase  training  options  for  some 

missions  that  require  interaction 

between  users 

YP’s  instruments  and  controls 

Increase  immersion  and  cues  to  task 

simulation 

performing 

Intuitive  Graphical  User  Interface  (GUI) 

Increase  usability 

After  Action  Review  (AAR) 

Increase  training  feedback 

Scenarios  with  navigational  aids  and 

Increase  realism,  immersion  and 

other  ships 

training 

Artificial  Intelligence  (Al)  for  scenario 

ships 

Increase  scenario  realism 

Mooring  lines  simulation 

Provide  mooring/unmooring  training 

and  increase  immersion. 

Anchor  and  chain  simulation 

Provide  anchoring  training  and 

increase  immersion. 

Radar  simulation 

Provide  radar  familiarization,  range 

and  bearing  source  of  information  and 

increase  immersion. 

2.  Limitations 

YPSim  is  not  designed  to  provide  the  following  capabilities  as  a  simulation 
training  system: 

•  Full  mission  training  to  YP’s  bridge  team 

•  Extremely  accurate  and  realistic  physical  model  of  the  YP 

•  Intelligent  Tutoring  System  feedback 
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C.  REQUIREMENTS 

The  following  requirements  for  YPSim  are  based  on  the  Mission 
Description  and  Task  Analysis  presented  in  Chapter  III. 

1.0  Functional  Requirements 

1.1  YPSim  shall  simulate  all  six  YP’s  training  missions. 

1.2  YPSim  shall  allow  the  user  to  totally  control  YP’s  engines 
RPM  and  rudder,  allowing  free  navigation  in  the  mission 
scenario. 

1.3  YPSim  shall  provide  a  scenario  editing  tool  for  instructor’s 
use. 

1.4  YPSim  shall  provide  a  Graphical  User  Interface  (GUI)  based 
on  video-game  style  menus  and  selection  of  options, 
allowing  the  user  to  intuitively  navigates  back  and  forth 
between  initialization,  setup  and  mission  execution. 

1.5  YPSim  GUI  shall  provide  access  to  menus  for  (a)  mission 
selection,  (b)  tutorials  for  each  mission,  (c)  configuration 
options,  (d)  help,  and  (e)  quit. 

1.6  YPSim  shall  provide  environmental  options  at  the  mission 
scenario  configuration  level  for  (a)  daylight,  (b)  sea  state,  (c) 
wind  direction  and  speed,  (d)  visibility  (fog),  (e)  sea  current, 
and  (f)  cloud  cover. 

1 .7  YPSim  shall  present  the  following  viewer  options: 

1.7.1  First  person,  from  inside  the  YP’s  bridge,  at  three 
positions  (a)  amidships,  (b)  portside  wing  and  (c) 
starboard  wing.  The  first  person  view  shall  be  able  to 
control  viewing  direction  in  both  azimuth  and 
elevation. 
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1.7.2  Third  person,  one  following  the  YP  with  a  fixed 
relative  position  from  astern,  and  another  option  with 
orbital  control  of  the  view. 

1.7.3  Binocular  view  when  in  first  person  mode  (at  YP’s 
bridge). 

1 .8  YPSim  shall  simulate  YP’s  equipment  that  represent  relevant 
cues  for  performing  the  tasks  of  Helmsman,  Lee  Helmsman 
and  OOD.  For  the  Brazilian  Naval  Academy  (BNA)  YPs,  the 
following  items  shall  be  included,  but  not  limited,  to  the 
simulation: 

1.8.1  Helm,  simulating  the  wheel  movement  when  rudder 
orders  are  executed. 

1 .8.2  Rudder  Angle  Indicator,  representing  the  current  YP’s 
rudder  angle  for  the  helmsman. 

1.8.3  Gyro  Compass,  representing  the  heading  dial 
movement  while  turning. 

1.8.4  Gyro  Compass  Repeater,  located  on  each  bridge 
wing  (port  and  starboard). 

1.8.5  Engine  Control,  representing  the  two  levers  that 
control  port  and  starboard  engine’s  RPM.  YPSim  shall 
simulate  the  rotational  movement  of  these  control 
levers  providing  a  visual  cue  of  the  current  engines 
RPM  status. 

1.8.6  Anemometer,  simulating  port  and  starboard  wind 
birds  with  direction  and  speed  of  the  apparent  wind. 
YPSim  shall  include  turbulence  effects,  adding  noise 
on  direction  and  speed  for  the  leeward  wind  bird. 
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1.8.7  Navigation  Radar,  simulating  antenna,  display  and 
basic  radar  functions.  The  radar  antenna  shall  rotate 
at  the  same  RPM  and  direction  of  the  real  YP’s  radar. 
The  basic  radar  functions  are  described  as,  but  not 
limited  to,  range,  Electronic  Bearing  Line  (EBL)  and 
Variable  Range  Marker  (VRM)  controls. 

1.8.8  Fathometer,  representing  the  current  depth  at  YP’s 
position. 

1.8.9  Speedometer,  representing  the  current  YP’s  speed 
over  the  water. 

1.8.10  Global  Positioning  System  (GPS),  representing  YP’s 
current  position  in  latitude  and  longitude,  course  over 
the  ground  (COG),  speed  over  the  ground  (SOG), 
bearing  to  the  next  waypoint  in  route  (BRG),  and 
estimated  time  of  arrival  to  the  next  waypoint  (ETA). 

1 .9  YPSim  shall  represent  the  nautical  chart  of  the  current  area 
of  operation.  YP’s  current  position  and  orientation  shall  be 
represented  in  this  nautical  chart  by  the  use  of  a  meaningful 
icon 

1.10  YPSim  shall  represent  an  instrument  panel,  available  during 
the  mission  execution  at  every  view  option.  This  panel  shall 
consolidate  relevant  information  from,  but  not  limited  to,  (a) 
apparent  wind,  (b)  heading,  (c)  speed,  (d)  engine  RPM 
status,  (e)  rudder  angle,  (f)  depth,  (g)  mission  elapsed  time. 

1.11  YPSim  shall  simulate  YP’s  wake  and  bow  spray  effect, 
proportional  to  ship  speed,  providing  visual  cue  of  ship 
movement  to  the  player. 
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1.12 


YPSim  shall  simulate  Man  Overboard  (MOB)  situations  with 
an  animated  character,  representing  the  individual,  floating 
in  the  ocean,  waving  for  rescue.  The  MOB  task  shall  be 
activated  by  scenario  triggers  or,  at  any  time,  by 
user/instructor  command. 

1.13  YPSim  shall  simulate  a  floating  orange  smoke  marker  for  the 
MOB  situation.  The  smoke  marker  shall  last  for  four  minutes 
from  the  moment  of  activation,  or  be  removed  from  the 
scene  upon  the  MOB  recovery.  The  activation  shall  occur  by 
the  user’s  command. 

1.14  YPSim  shall  simulate  a  standard  YP  lifebuoy  for  the  MOB 
situations,  respecting  its  shape,  size  and  colors.  The  lifebuoy 
activation  shall  be  given  by  the  user’s  command,  and 
removed  from  the  scene  after  recovering  the  MOB. 

1.15  YPSim  shall  simulate  YP’s  whistle.  Whistle  activation  shall 
be  given  by  the  the  user  continuously  pressing  the  key  or 
GUI  button,  and  deactivating  upon  its  release. 

1.16  YPSim  shall  simulate  flag  hoisting  in  YP’s  mast  by  the  user’s 
commands.  A  specific  GUI  shall  provide  the  basic 
functionality  required  for  the  user’s  control  of  flag  selection, 
hoisting  and  hauling  it  down. 

1.17  YPSim  shall  provide  a  scoring  system  based  upon  each 
mission  performance  metrics.  Scores  shall  be  displayed  in  a 
debriefing  menu,  after  mission  execution.  The  debriefing 
menu  shall  display  individual  scores  per  metric  evaluated 
and  an  overall  result  by  adding  all  of  them  in  a  meaningful 
way. 


50 


1.18  YPSim  shall  evaluate  the  user’s  performance  at: 


1.18.1  MOB  missions  by  (a)  recovery  time,  (b)  MOB  safety 
violation,  (c)  turning  procedures,  (d)  administrative 
procedures,  (e)  recovery  distance,  (f)  recovery  side 
evaluation,  (g)  number  of  engine  and  rudder  orders, 
(h)  engine  overload,  and  (i)  YP’s  safety  violation. 

1 .18.2  Anchoring  missions  by  (a)  mission  time,  (b)  anchoring 
maneuvering  procedures,  (c)  administrative 
procedures,  (d)  anchoring  precision,  (e)  number  of 
engine  and  rudder  orders,  (f)  engine  overload,  and  (g) 
YP’s  safety  violation. 

1 .18.3  Mooring/unmooring  missions  by  (a)  mission  time,  (b) 
mooring/unmooring  maneuvering  procedures,  (c) 
administrative  procedures,  (d)  number  of  engine  and 
rudder  orders,  (e)  engine  overload,  (f)  YP’s  safety 
violation,  and  (g)  number  of  YP  hits  at  the  pier. 

1 .18.4  Underway  Replenishment  (UNREP)  missions  by  (a) 
UNREP  maneuvering  procedures,  (b)  administrative 
procedures,  (c)  engine  overload,  and  (d)  YP’s  safety 
violation. 

1 .18.5  Tactical  Maneuvers  missions  by  (a)  execution  time 
per  evolution  in  the  formation,  (b)  stationing 
procedures,  (c)  administrative  procedures,  (d)  engine 
overload,  and  (d)  YP’s  safety  violation. 

1.18.6  Basic  Navigation  missions  by  (a)  execution  time,  (b) 
rules  of  the  road  procedures,  (c)  offset  from  the 
navigation  route,  (d)  engine  overload,  and  (d)  YP’s 
safety  violation. 
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1.19  YPSim  shall  simulate  an  anchor  buoy  marking  the  anchor’s 
position.  This  buoy’s  shape,  size  and  color  shall  match  the 
real  buoy  used  at  the  YPs. 

1.20  YPSim’s  mission  scenarios  that  simulate  real-world 
geographical  areas  shall  provide  accurate  terrain  geometry 
and  coordinate  matching. 

1.21  YPSim  shall  provide  mission  scenarios  with  3D  surface 
contacts  representing  the  real-world  types  of  ships  and  boats 
expected  for  that  given  area. 

1.22  YPSim  shall  provide  mission  scenarios  with  navigational 
aids,  such  buoys,  lighthouses  and  lead  marks,  represented 
in  the  simulation.  The  shape,  color  and  lights  of  these  3D 
objects  shall  accurately  match  their  real-world  instances. 

1.23  YPSim  shall  provide  an  Artificial  Intelligence  (Al)  agent  for 
simulating  the  behavior  of  a  helmsman  steering  the  YP.  A 
specific  GUI  for  controlling  this  agent  shall  be  provided, 
allowing  the  user  to  use  or  not  use  the  Al  agent  and  issue 
rudder  commands. 

1.24  YPSim  shall  provide  an  Al  agent  for  controlling  ships  that 
directly  interact  with  the  user’s  YP.  This  agent  shall  control 
both  his  ship’s  course  and  speed,  simulating  more  realistic 
movements  in  the  scenario.  Ships  (usually  other  YPs) 
participating  in  tactical  maneuvers  and  Underway 
Replenishment  (UNREP)  operations  shall  use  this  agent  for 
movement  control. 

1.25  YPSim  shall  handle  collision  detection  between  the  user’s 
YP  and  (a)  terrain,  (b)  other  surface  contacts,  and  (b) 
navigational  aids. 
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1 .26  YPSim  shall  provide  control  of  YP’s  damage  level  occurred 
by  eventual  collisions  during  the  mission  execution.  A 
negative  reinforcement  for  every  collision  shall  be  applied  in 
the  user’s  score  at  that  given  mission.  A  maximum  damage 
threshold  shall  be  set  in  the  mission  scenario  configuration, 
allowing  different  levels  of  difficulty  for  the  mission  execution. 

1.27  YPSim  shall  provide  a  realistic  ocean  surface  with  sea  state 
(wave  height)  and  color  settings  in  the  mission  scenario 
configuration. 

1.28  YPSim  shall  represent  navigation  routes  and  waypoints  in 
the  3D  scenario,  as  a  reference  for  the  user.  This 
functionality  availability  shall  be  set  at  the  mission  scenario 
configuration.  When  available,  this  reference  shall  be 
switched  on/off  by  user/instructor  command  during  mission 
execution. 

1.29  YPSim  shall  simulate  a  wind  effect  that  is  initially  set  in  the 
mission  scenario  configuration.  This  environmental  factor 
shall  affect  YP’s  physical  model,  anemometer  indicators  and 
wind  bird  state.  A  noise  component  to  the  wind  direction  and 
speed  shall  be  introduced  and  controlled  in  the  mission 
scenario  configuration. 

1.30  YPSim  shall  simulate  a  sea  current  effect  that  is  initially  set 
in  the  mission  scenario  configuration.  Current’s  direction  and 
speed  shall  affect  YP’s  physical  model. 

1.31  YPSim  shall  simulate  YP’s  mooring  lines  for 
mooring/unmooring  missions.  A  realistic  behavior  for  the 
mooring  lines  shall  be  simulated,  affecting  the  YP’s  physical 
model  as  expected  in  real  life.  A  specific  GUI  for  mooring 
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lines  interaction  shall  be  provided,  allowing  the  user  to  give 
the  basic  commands  for  controlling  them. 

1.32  YPSim  shall  simulate  YP’s  anchor  and  its  respective  chain, 
for  anchoring  missions.  Factors  such  as  drifting,  weight, 
chain  catenary  effect  and  nature  of  the  seabed  shall  be 
included  in  the  anchor’s  physical  model.  A  specific  GUI  for 
anchor  interaction  shall  be  provided,  allowing  the  user  to 
give  the  basic  commands  for  controlling  it. 

1.33  YPSim  shall  simulate  YP’s  rudder  movements,  not  only 
representing  changes  in  the  rudder  angle  indicator,  but  also 
moving  the  rudder  geometry  itself  by  the  current  of  angle 
ordered  by  the  user. 

1.34  YPSim  shall  simulate  YP’s  propellers  movements,  rotating 
the  propellers  geometry  at  the  proper  direction  and  speed, 
proportional  to  engines  RPM. 

1.35  YPSim  shall  provide  network  capabilities  allowing 
interoperability  of  multiple  instances  of  the  simulation.  The 
network  infrastructure  shall  be  able  to  connect  at  least  three 
instances  of  YPSim  running  the  same  mission  scenario. 

1.36  YPSim  shall  adopt  dead  reckoning  techniques  for  more 
realistic  movements  of  remotely  controlled  actors  in  the 
simulation. 

1.37  YPSim  shall  be  initialized  in  full  screen  mode  without  window 
decoration  frame. 

1 .38  YPSim  shall  allow  the  user/instructor  to  pause  the  simulation 
at  any  time. 

1 .39  YPSim  shall  provide  After  Action  Review  (AAR)  functionality. 

2.0  Nonfunctional  Requirements 
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2.1  Usability 


2.1.1  YPSim  shall  provide  an  entertaining  instructional 
environment  related  to  navigation  and  shiphandling 
topics  applied  to  a  naval  academy’s  YPs. 

2.1.2  YPSim  shall  replicate  YP’s  geometry  and 
characteristics  of  maneuver,  providing  good 
immersion  to  its  users. 

2.1.3  YPSim  shall  be  used  with  or  without  an  instructor’s 
supervision. 

2.1.4  YPSim  shall  be  used  as  standalone  or  connected  to  a 
network. 

2.1.5  YPSim  shall  provide  an  intuitive  interface,  allowing  a 
quick  learning  process  to  its  users. 

2.1.6  YPSim  shall  have  multiple  input  devices  options  for 
controlling  the  YP  platform. 

2.1.7  YPSim  shall  have  the  option  for  multiple-  or  single¬ 
screen  display. 

2.1.8  YPSim  shall  have  an  easy  installation  process. 

2.1.9  YPSim  shall  have  a  help  menu  containing  instructions 
about  its  controls. 

2.2  Reliability 

2.2.1  YPSim  shall  be  a  reliable  application,  supporting  long 
periods  of  running  time. 

2.3  Performance 

2.3.1  YPSim  shall  run  in  a  laptop  or  desktop  PC. 
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2.3.2  YPSim  shall  generate,  at  minimum,  20  frames  per 
second  using  the  recommended  hardware 
configuration  listed  in  section  A.5. 

D.  PRODUCT  FEATURES 


YPSim’s  most  important  features  can  be  summarized  into  three 

categories,  called  System,  YP  Platform  and  Scenario.  First,  we  grouped  features 

regarding  generic  capabilities  of  the  system.  The  second  group  represent  YPSim 

characteristics  specific  for  the  simulated  ship.  Features  that  affect  the  scenario 

where  the  simulation  takes  place  are  listed  in  the  last  group. 

The  following  list  is  not  complete  and  represents  only  the  most  important 

features  of  the  system,  for  synopsis  purposes  and  better  understanding  of 

requirement  needs. 

1.0 

System  Features 

1.1 

Simulation  of  six  basic  YP’s  mission 

1.2 

Intuitive  Graphical  User  Interface  (GUI) 

1.3 

Scoring  system 

1.4 

Network  capabilities 

1.5 

Realistic  3D  graphics 

1.6 

Multiple  input  devices 

1.7 

Multiple  screen  options 

1.8 

After  Action  Review 

1.9 

Multiple  view  points 

1.10 

Collision  detection 

1.11 

Al  agents  for  ships  in  scenario 

2.0 

YP  Platform  Features 
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2.1  Fairly  close  to  reality  physical  model 

2.2  Radar  simulation 

2.3  Nautical  chart  simulation 

2.4  Anemometer  simulation 

2.5  Fathometer  simulation 

2.6  Al  Helmsman  agent 

2.7  Binocular  view 

2.8  Whistle 

2.9  Heads  Up  Display  (HUD)  for  instruments 

2.10  Mooring  lines  simulation 

2.11  Anchor  and  chain  simulation 

3.0  Scenario 

3.1  Realistic  scenarios  of  the  YP’s  area  of  operation 

3.2  Scenario  editing 

3.3  Fairly  realistic  ocean  surface 

3.4  Environmental  control 

3.5  Wind  effects 

3.6  Sea  current  effects 

E.  ACCEPTABLE  HARDWARE  REQUIREMENTS  TO  USER 

The  following  systems  characteristics  are  required  in  order  to  run  YPSim 
with  good  results: 

•  Processor:  dual  core  CPU  @  2.3GHz,  minimum 

•  Memory:  2  GB  minimum 

•  Disk  Space:  450  MB  to  install 
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•  Graphics  Card:  256  MB  minimum,  with  support  to  OpenGL  2.0 

or  above  (NVidia  GeForce  7xxx  series  or  ATI  Radeon  HD  2xxx 
series  and  above) 

Operating  System:  Windows  XP  or  above 
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V.  SYSTEM  DEVELOPMENT 


A.  OVERVIEW 

The  YPSim  is  a  proof-of-concept  application,  developed  along  the  two 
years  of  the  author’s  master’s  degree  research.  Using  the  same  architecture 
proposed  by  Salvatore  (2005),  Ernst  (2006),  and  Toledo  (2006)  in  their  designs, 
YPSim  was  developed  on  top  of  the  Delta3D  game  simulation  engine.  The 
underlying  details  about  the  Delta3D  application  and  its  dependencies  is  beyond 
the  scope  of  this  thesis  and  can  be  found  in  the  previously  mentioned  theses 
works.  This  chapter  is  dedicated  to  describe  all  the  steps  taken  between  the 
idealization  and  the  currently  available  prototype  version  of  YPSim. 


Figure  15.  High-level  view  of  YPSim's  state  cycle. 

YPSim  is  a  Delta3D  (version  2.4.0)  Game  Manager  (GM)  application 
(Toledo,  2006)  that  loads  some  important  GM  components  and  one  selected 
scenario  file  containing,  at  a  minimum,  one  Ocean  Actor  and  one  Yard  Patrol 
actor  (YPActor).  At  the  initialization  of  YPSim,  components  with  specific  code 
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functionalities  are  added  to  the  GM,  such  as  the  one  responsible  for  the  creation 
of  a  graphical  user  interface  (GUIComponent  on  Figure  15.  ).  After  initialized,  the 
YPSim  will  present  a  GUI  to  the  user,  where  he/she  can  navigate  throughout  the 
many  menu  options  available,  selecting  options,  accessing  tutorials,  help  and 
mission  selection.  Having  concluded  all  the  menu  selections  desired,  the  user 
selects  one  combination  of  (a)  YP,  (b)  environment,  and  (c)  mission  to  play,  and 
loads  the  scenario  file.  The  scenario  file  sets  the  stage  for  the  simulation  with  the 
actors,  such  as  user  YP,  ships,  terrain,  ocean,  and  environment,  describing  their 
specific  properties  for  that  mission.  Once  the  scenario  is  loaded,  the  user  is 
ready  to  control  his/her  YP  in  order  to  accomplish  the  goal  for  that  mission. 
Figure  15  presents  a  high-level  view  of  the  YPSim’s  states  cycle,  giving  a 
graphical  interpretation  to  the  sequence  described  in  this  paragraph. 

The  biggest  constraint  to  the  YPSim’s  prototype  development  cycle  was 
time.  The  author’s  lack  of  programming  background,  3D  graphics  creation,  and 
class  obligations  limited  the  number  of  features  implemented  in  this  game-based 
simulation  project.  YPSim  beta  version  0.13,  the  proof-of-concept  prototype,  has 
met  most  of  the  requirements  listed  in  Chapter  IV.  For  the  scope  of  this  thesis, 
only  the  Man  Overboard  (MOB)  and  Anchoring  missions  were  implemented  in 
YPSim  v0.13,  using  two  scenario  environments.  The  first  environment  represents 
the  surroundings  of  the  Brazilian  Naval  Academy  (BNA)  at  the  Guanabara  Bay 
(Rio  de  Janeiro  -  Brazil),  while  the  second  is  a  set  of  fictitious  islands  at  open 
sea.  Some  important  functionality,  such  as  After  Action  Review  (AAR),  could  not 
be  achieved  due  to  development  time  limitations  and  had  to  be  listed  as  future 
research  work.  The  following  sections  describe  the  development  of  the  most 
important  pieces  of  YPSim  v0.13. 

B.  3D  MODELS 

YPSim  uses  OSG  and  IVE  file  formats  for  the  3D  meshes  loaded  into  the 
simulation.  These  file  formats  are  the  most  commonly  used  formats  in 
applications  developed  using  Delta3D  and  OpenSceneGraph  (OSG).  While  OSG 
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are  text  files  containing  the  model  information  and  are  relatively  easy  to 
manipulate  in  any  text  editor,  IVE  files  contain  the  same  information  and  textures 
images  in  a  binary  format,  making  the  loading  process  more  efficient.  The  3D 
models  used  in  YPSim  come  from  three  different  sources: 

•  Created  by  author 

•  Delta3D  asset  library 

•  Laboratorio  de  Sistemas  Digitais  (LSI)  -  USP  (Digital  Systems 
Laboratory,  University  of  Sao  Paulo) 

We  used  X3D  (Extensible  3D  Graphics)  Editor,  Blender  and  3D  Studio 
Max™  software  for  model  creation.  Models  from  the  Delta3D  asset  library  were 
ready  to  use,  in  both  OSG  and  IVE  formats,  and  often  with  the  source  3D  Studio 
Max  file  available  for  further  editing.  The  LSI’s  models  were  initially  created  using 
Autodesk  Maya™  for  another  simulation  project  for  the  Brazilian  Navy.  These 
models  were  not  OSG  ready  and  required  further  manipulation  using  3D  Studio 
Max™.  Appendix  A  contains  detailed  information  about  the  3D  models  used  in 
YPSim. 

C.  YP’S  PHYSICAL  MODEL 

The  physical  model  is  one  of  the  most  important  pieces  of  YPSim’s  code. 
Its  origins  were  in  an  application  developed  in  Delta3D  for  demonstrations 
purposes  called  WaterSprint.  The  WaterSprint  was  implemented  by  Erik 
Johnson,  the  Delta3D’s  software  engineer,  in  order  to  create  a  demo  application 
to  explore  the  dtOcean  library  used  to  simulate  ocean  effects.  WaterSprint  had  a 
physical  model  implemented  to  simulate  a  rigid  inflatable  boat  (RIB)  with  an 
outboard  motor  moving  over  the  ocean  according  to  the  user’s  input  command. 
Its  physical  model  was  fairly  simple  and  efficient  in  controlling  the  RIB  with 
realistic  movements.  The  initial  idea  was  to  reuse,  as  much  as  possible,  pieces  of 
code  from  the  WaterSprint  model  into  YPSim,  refining  the  model  one  piece  at  a 
time,  according  to  the  YP’s  characteristics. 
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Our  physical  model,  detailed  in  Appendix  D,  uses  Open  Dynamics  Engine 
(ODE)  and  its  correspondent  Delta3D  rigid  body  wrapper  functions  to  apply 
forces  on  the  YP  at  each  physical  simulation  step  (1/1000  seconds  step  size). 
This  model  is  not  designed  to  be  complete,  and  several  simplifications  were 
made  in  order  to  achieve  real-time  performance,  with  realistic  behavior  for  a 
game  designed  to  offer  a  very  basic  type  of  training. 

D.  YP’S  MOORING  LINES 

Mooring  lines  have  an  important  role  during  mooring  and  unmooring 
maneuvers,  being  responsible  for  pivoting  and  securing  the  ship  to  the  pier. 
Learning  how  to  handle  a  ship  using  mooring  lines  is  one  of  the  most  important 
types  of  training  aboard  the  YP.  The  scope  of  this  thesis  is  directed  towards  the 
Man  Overboard  and  Anchoring  missions,  which  do  not  require  the  use  of  mooring 
lines.  However,  because  of  its  importance  for  future  implementations,  basic 
mooring  lines  functionality  was  added  to  the  YPSim.  Detailed  information  about 
the  mooring  lines  implementation  are  given  in  Appendix  B. 

E.  YP’S  ANCHOR  AND  CHAIN 

An  anchor  model  was  developed  for  YPSim’s  Anchoring  missions, 
allowing  the  simulation  of  the  physics  involved  in  that  task.  Anchoring  the  YP  is 
not  a  simple  process  and  its  complexity  is  a  product  of  many  important  variables, 
such  as  wind,  current,  nature  of  the  seabed,  and  OOD’s  ship-handling  skills.  A 
model  capable  of  simulating  some  of  the  basic  dynamics  of  the  anchoring 
process  is  crucial  in  providing  valid  training  for  YPSim’s  Anchoring  mission.  More 
detailed  descriptions  of  the  anchor  and  chain  model  are  provided  in  Appendix  C. 

F.  OCEAN  MODEL 

YPSim  uses  a  dtOcean  actor  in  each  one  of  its  scenario  files,  for 
environment  control  and  realistic  ocean  rendering.  The  dtOcean  is  a  Delta3D 
actor  that  contains  objects  of  the  osgOcean  (version  1.0.1)  library.  The  scenario 
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configuration  files  can  set  several  parameters  of  the  ocean  surface,  such  as 
resolution,  choppiness,  wind  speed,  height,  reflection,  water  silt  and  color.  The 
current  version  of  dtOcean  used  in  YPSim,  also  allows  the  configuration  of  sea 
current  parameters  that  are  used  in  the  YP  physical  model  calculations. 

G.  GAME  COMPONENTS 

YPSim  is  a  game  application,  subclass  of  the  dtGame::GameApplication 
class.  Game  applications  are  characterized  by  the  use  of  the  Delta3D’s  Game 
Manager  (GM)  message  system  to  exchange  important  information  between 
specific  components,  as  explored  by  Toledo  (2005)  in  his  design.  GM 
components  used  in  YPSim  are  subclasses  of  dtGame::GMComponent, 
designed  to  provide  well  defined  functionality  to  the  simulation,  using  the  GM 
infrastructure.  One  of  the  biggest  advantages  of  the  GM  infrastructure  when 
adding  functionality  to  the  code,  is  the  facility  in  which  new  pieces  can  be  added 
without  changing  other  components.  The  message  system,  used  as  a  means  of 
communication  between  components,  provides  an  excellent  tool  for  connecting 
the  major  pieces  of  the  simulation. 

YPSim  has  eleven  major  Game  Components  in  its  architecture: 

•  YPComponent:  responsible  for  directly  handling  messages  and 
settings  to  user’s  YP,  an  instance  of  the  YPActor  class. 

•  CameraComponent:  responsible  for  handling  camera  position  and 
modes  of  operation,  handling  messages  concerning  the  scene 
camera.  The  camera  corresponds  to  user’s  eye  on  the  scene. 

•  GUIComponent:  responsible  for  the  Graphical  User  Interface 
(GUI).  Handles  messages  that  affect  the  GUI  and  sends  messages 
based  on  user  inputs  on  the  GUI  options. 

•  HelmsmanComponent:  corresponds  to  the  helmsman  agent.  Has 
a  great  interaction  with  the  YPComponent,  sending  commands  to 
control  YP’s  rudder.  This  component  has  its  own  GUI  to  handle 
user’s  inputs  and  information  output  from  the  helmsman  Artificial 
Intelligence  (Al). 

•  InitComponent:  responsible  for  basic  initialization  settings  on  the 
application,  when  the  mission  scenario  is  changed. 
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•  InputComponent:  responsible  for  managing  the  input  devices. 
Handles  messages  to  set  the  selected  device,  configuring  it,  and 
processing  user’s  commands.  Always  handles  inputs  from 
keyboard  and  mouse,  even  when  other  devices  are  selected  as  the 
main  controller. 

•  NetComponent:  responsible  for  handling  network  connections, 
and  packets  reception  and  transmission.  Creates  and  update  the 
YPs  corresponding  to  the  other  instances  of  YPSim  connected  on 
the  network.  YPSim  uses  a  Client/Server  connection,  using  specific 
UDP  protocol  to  send  its  YP  current  state. 

•  MOBComponent:  responsible  for  managing  the  Man  Overboard 
(MOB)  task  and  the  character  animation  (a  simple  hand  waving  for 
rescue).  This  component  handles  the  conditions  to  drop  and 
recover  the  MOB,  sending  and  receiving  messages  necessary  to 
execute  the  task. 

•  RadarComponent:  manages  the  radar  simulation.  Basically 

handles  messages  for  controlling  the  radar,  such  as  on/off,  range, 
Electronic  Bearing  Line  (EBL)  and  Variable  Range  Marker  (VRM). 
Also  controls  the  radar  screen  appearance,  if  inside  the  bridge,  as  a 
regular  radar,  or  Heads-up  Display  (HUD). 

•  ScoringComponent:  responsible  for  assessing  user’s 

performance  in  a  given  mission.  Calculates  user  score  according  to 

the  type  of  mission  and  scenario  executed.  Handles  messages  to 
terminate  mission  and  create  debriefing  menus. 

H.  YPSIM  ACTORS 

1 .  YPActor 

The  YPActor  is  the  main  actor  present  on  YPSim.  Actors  are  the  entities 
that  interact  in  the  simulation  scenario,  and  the  YPActor  is  the  only  one  under  the 
user’s  direct  control.  Every  scenario  configuration  file  must  contain  one  instance 
of  the  YPActor  class,  representing  the  user’s  YP.  This  class  is  a  subclass  of  the 
dtActors::GameMeshActor  that  contains  a  set  of  specific  objects  and  methods 
designed  to  simulate  a  fully  functional  YP  controlled  by  the  user. 

A  high-level  view  of  the  YPActor  class  can  be  visualized  in  Figure  16, 

presenting  the  most  used  public  methods  available  for  the  Game  Components,  in 

this  case  YPComponent  and  InputComponent.  The  YPActor  owns  instances  of 
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the  Buoy,  YPPhysical,  MooringLines,  Anchor  and  YPEffects  classes.  Each  one  of 
this  objects  will  be  responsible  for  a  specific  functionality  inside  the  YPActor, 
accessing  important  information  and  other  objects  inherited  from  the 
dtActors::GameMeshActor  class.  All  of  them  need  to  access  the  ODE  body 
inside  the  GameMeshActor  in  order  to  apply  forces,  retrieve  velocity  information 
or  create  joints.  Others,  like  YPPhysical  and  MooringLines,  need  to  access 
nodes  inside  the  3D  Model  to  apply  changes  in  the  geometry  to  be  rendered  on 
scene. 


Controls  and  applies  control 

propellers  and  rudders 
forces.  Access  YP  3D 
model  and  control  moving 
parts  geometries 


Figure  16.  High-level  view  of  the  YPActor  class. 


2.  ShipDummyActor 

The  ShipDummyActor  class  is  used  for  creating  nonrealistic  ships  on  the 
scenario.  A  course  and  speed  can  be  configurable  on  the  mission  scenario  file, 
and  the  this  actor  will  move  in  a  straight  line  indefinitely  during  the  runtime.  This 
ship  actor  is  not  intended  to  handle  collisions,  ocean  response  and  course,  or 
speed  control,  making  it  computationally  simple  to  populate  the  scenario. 
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ShipDummyActor  is  a  subclass  of  dtActors::GameMeshActor  and  allows  the  user 
to  select  which  3D  model  to  represent  it  on  the  scene. 

3.  ShipSmartActor 

When  more  realistic  behavior  is  expected  for  a  ship,  the  ShipSmartActor 
can  be  used.  Actors  of  this  class  have  a  small  physical  model  that  will  handle 
ocean  effects  (buoyance),  and  course  and  speed  control,  and  have  sound  and 
particle  effects  to  simulate  the  ship’s  engines,  bow  splash  and  wake.  This  yields 
to  a  good  and  realistic  behavior  that  can  be  used  to  simulate  ships  that  will 
directly  interact  with  the  user’s  YP,  usually  visualized  at  closer  distance.  The 
ShipSmartActor  class  was  primarily  created  to  simulate  other  YPs  on  tactical 
maneuvers  or  Underway  Replenishment  (UNREP)  missions.  In  both  situations, 
ships  can  change  course  and  speed  during  the  runtime,  and  will  be  at  close 
distance  to  the  user’s  YP.  The  drawback  of  using  ShipSmartActors  on  a  scenario 
is  the  intensive  processing  involved  in  its  physics  step,  more  than  a  simple 
ShipDummyActor  and  less  than  YPActor. 

I.  GRAPHICAL  USER  INTERFACE  (GUI) 

Developed  using  the  dtGUI  and  CEGUI  libraries,  a  graphical  interface  was 
created  in  order  to  allow  user  interaction  with  the  simulation.  YPSim  has  basically 
two  states  during  its  execution:  (a)  menu,  and  (b)  running. 

Most  of  the  GUI  functionality  is  used  at  the  menu  state,  when  the  user  is 
navigating  through  the  options  available  on  the  screen,  using  a  mouse.  Using  the 
menus  available,  the  user  can  select  configuration  options  for  screen  type,  input 
device  and  mission  selection.  He/she  can  also  access  tutorials  and  help 
information  menus,  the  contents  of  which  were  not  implemented  for  the  scope  of 
this  thesis. 
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Figure  17.  Screenshot  of  YPSim’s  GUI  menus. 


During  the  running  state  of  the  simulation,  GUI  functionality  is  available  for 
controlling  the  Helmsman  Al,  quitting  the  current  mission  and  debriefing 
information.  During  the  mission  execution,  information  about  the  YP’s 
instruments  are  displayed  using  a  different  technique.  Instead  of  using 
dtGUI/CEGUI  for  displaying  instrument  information,  the  author  used  3D 
geometries  with  DOFTransform  and  Switch  nodes.  These  OSG  special  nodes 
allow  manipulation  on  objects  rendered  geometries,  giving  extra  flexibility  for 
creating  effects  such  as  radar  screen,  nautical  chart,  and  dials  and  digits  on  the 
instrument  panel  (Figure  18). 
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Figure  18.  Screenshot  of  YPSim's  GUI  at  runtime. 


J.  NAVIGATION  RADAR 

We  modeled  a  simple  navigation  radar  found  inside  the  YP’s  bridge  in 
order  to  simulate  the  basic  functionality  of  this  important  piece  of  equipment.  The 
radar  model  has  the  capability  of  measuring  bearings  and  distances  of  landmarks 
and  surface  contacts.  The  Officer  of  the  Deck  (OOD)  uses  these  radar  functions 
for  most  of  the  missions  executed  in  YPSim.  Appendix  E  presents  more  detailed 
explanations  of  the  radar  implementation. 

K.  NAUTICAL  CHART 

In  order  to  simulate  the  positioning  information  provided  by  the 
Quartermaster  of  the  watch  (QOW)  or  GPS  plotter,  a  nautical  chart  functionality 
was  developed.  The  virtual  nautical  chart  can  be  displayed  on  the  screen  by  the 
user’s  request,  showing  a  YP’s  icon  at  the  center  of  the  chart  oriented  to  its 
present  head.  The  chart  itself  is  an  instance  of  the  Detla3D  dtCore::Object  with  a 


68 


special  3D  model  loaded  as  a  geometry.  This  model  contains  a  flat  plane  with  a 
texture  of  the  simulated  nautical  chart  with  the  YP’s  icon.  The  icon  plane  has  a 
DOFTransform  node  on  top  of  it,  allowing  runtime  manipulation  for  heading 
control.  By  manipulating  the  texture  coordinates  of  the  nautical  chart  geometry 
during  the  runtime,  we  were  able  to  update  the  YP’s  icon  position  and  provide 
zoom  control. 

L.  INPUT  DEVICES 

The  standard  input  devices  used  by  YPSim  are  keyboard  and  mouse.  In 
order  to  explore  YPSim  as  a  game  and  provide  more  flexibility  to  its  usability, 
other  common  types  of  devices  were  configured  to  provide  commands  to  the 
user’s  YP. 


Figure  19.  YPSim  input  devices.  From  left  to  right:  keyboard/mouse, 
flight  yoke,  Ship  Driver  Controller(TM),  and  PS3  controller. 


M.  CAMERA  VIEWS 

Four  basic  camera  view  modes  were  implemented,  allowing  different 
perspectives  of  the  scene  during  the  mission  execution.  This  flexibility  is 
important  in  order  to  allow  users  to  visualize  the  environment  from  different 
angles.  The  camera  modes  are  as  follow: 
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•  First  person:  user’s  eyes  are  located  inside  the  YP’s  navigation 
bridge.  User  can  select  three  different  locations  inside  the  bridge, 
left  wing,  centered,  and  right  wing.  A  binoculars  view  is  available 
during  this  camera  mode,  magnifying  user’s  field  of  view. 

•  Follow:  users  have  a  third-person  view  of  the  YP,  maintaining  fixed 
relative  position  at  the  YP’s  stern. 

•  Orbit  relative:  users  also  have  a  third-person  view  of  the  YP  but 
controlling  the  relative  position  (bearing  and  distance)  to  the  YP. 
This  mode  allows  the  user  to  keep  looking  the  YP  at  the  same 
angle  during  turns. 

•  Orbit  true:  has  a  similar  effect  to  relative,  but  keeps  the  same  true 
bearing  and  distance  to  the  YP.  In  this  mode,  if  the  YP  turns,  the 
user  will  see  it  from  another  angle,  making  it  easy  to  notice 
changes  in  course. 

N.  SCENARIO  CREATION 

Scenario  configuration  files,  also  called  maps,  contain  the  actors’ 
properties  composing  the  simulated  mission.  These  files  are  edited  in  a  Delta3D 
application  called  STAGE  and  saved  in  a  XML  format,  under  the  .map  extension. 
STAGE  makes  it  easy  to  change  an  actor’s  basic  parameters,  such  as  position 
and  orientation,  or  more  complex  settings  particular  to  a  given  class,  such  as  the 
sea  current  direction  of  the  ocean  actor  (Figure  20).  Maps  are  loaded  after  the 
user  selects  the  START  button  under  the  mission  selection  menu,  changing 
YPSim  to  the  running  state,  and  unloaded  every  time  the  simulation  goes  back  to 
the  menu  state. 
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Figure  20.  Screenshot  of  a  scenario  editing  using  Delta3D's  STAGE 

application. 


Ten  scenario  configuration  files  were  built  for  YPSim,  each  one 
representing  a  combination  of  two  environments  (Guanabara  Bay  or  Islands  at 
Open  Sea)  and  five  missions  (Anchoring,  Navigation,  Replenishment  At  Sea, 
Man  Overboard  and  Mooring).  Each  map  has  a  specific  configuration  for  wind, 
current,  ocean  color,  surface  contacts  present  on  the  scene,  and  tasks  to 
accomplish.  For  the  purpose  of  this  thesis,  only  the  Man  Overboard  (MOB)  maps 
were  completely  implemented  with  the  tasks  and  scoring  elements.  Maps  for  the 
other  missions  exist,  but  do  not  have  the  tasks  part. 

O.  SCORING  SYSTEM 

Scoring  systems  for  YPSim  should  follow  the  instructions  for  performance 
assessment  presented  in  Chapter  III  of  this  thesis.  The  system  should  evaluate 
user  actions  according  to  metrics  relevant  to  each  specific  mission.  For  the  scope 
of  this  thesis  research,  only  the  MOB  mission  had  the  scoring  system 
implemented. 


71 


The  MOB  scenario  consists  of  a  simple  navigation  route  marked  by 
several  pair  of  buoys  and  a  final  waypoint  where  the  MOB  will  be  dropped  upon 
arrival.  The  user  will  first  navigate  along  the  route,  trying  to  stay  as  close  as 
possible  to  the  intended  route  and  reach  the  MOB  waypoint  as  fast  as  he/she 
can.  Once  the  MOB  is  dropped,  the  user  has  150  seconds  to  recover  the 
individual.  Mission  ends  under  two  conditions:  when  MOB  is  picked,  or  after  150 
seconds  of  rescue  time.  The  scoring  system  for  the  MOB  mission  is  measuring 
the  elapsed  time  of  the  navigation  and  rescue  part,  the  number  of  input 
commands  (rudder  and  engines)  and  the  distance  offset  from  the  center  of  the 
route.  Other  performance  metrics  established  for  the  MOB  mission  on  the 
YPSim’s  requirements  were  excluded  from  the  scope  of  this  thesis. 
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VI.  YPSIM  TESTING 


The  development  of  YPSim  was  a  continuous  process  that  took  two  years 
to  achieve  the  current  proof-of-concept  version  (YPSim  v0.13).  Considering  the 
importance  of  keeping  a  user-centered  design  for  this  game-based  simulation, 
we  decided  to  make  several  releases  along  the  way,  enabling  feedback  from 
users.  The  feedback  was  used  to  correct  design  issues,  code  verification  and 
improve  usability  of  the  application.  We  used  four  milestone  releases  of  YPSim  to 
achieve  our  goal  of  having  a  polished  proof-of-concept  prototype. 

The  first  release  occurred  during  the  10th  Annual  MOVES  Research  and 
Education  Summit  open  house  event  (July  14,  2010),  when  a  demo  of  the  first 
release  of  YPSim  was  made  to  the  public  (YPSim  vO.1).  The  second  milestone 
was  a  demo  of  YPSim  v0.5  at  the  Interservice/Industry  Training,  Simulation  and 
Education  Conference  (l/ITSEC)  2010,  five  months  after  the  previous  release 
(December  2010).  The  next  release  was  made  during  the  following  MOVES  open 
house  in  2011,  when  version  0.11  was  demoed  in  July  13,  2011.  Finally,  after 
having  polished  the  last  prototype  version  of  the  simulator,  YPSim  v0.13  was 
released  at  the  Brazilian  Naval  Academy  (BNA)  for  the  user  acceptance  survey 
described  in  Chapter  VII. 

A.  MOVES  OPEN  HOUSE  DEMO  RELEASE  (2010) 

In  July  2010,  the  first  stable  prototype  of  YPSim  was  released  for  public 
use  during  the  MOVES  open  house  event  of  the  Annual  Research  and  Education 
Summit.  This  version  was  the  first  chance  to  test  the  basic  simulation  platform, 
consisting  of  the  ocean  model,  a  coarse  physical  model  implementation  for  the 
YP,  and  the  terrain  3D  model  of  the  Guanabara  Bay  (Rio  de  Janeiro,  Brazil), 
including  BNA’s  surroundings.  This  public  release  represented  our  first  chance  to 
get  feedback  from  the  modeling  and  simulation  community  regarding  the  YPSim 
concept  of  operation. 
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The  demo  was  configured  using  YPSim  running  in  a  desktop  computer 
connected  to  the  MOVES  Institute  three-screen  CAVE©  projection  system  and  a 
flight  yoke  controller.  The  selected  visualization  interface,  using  a  CAVE,  allowed 
users  to  have  a  180-degree  horizontal  field.  Volunteer  users  were  allowed  to 
handle  the  virtual  YP  through  a  green  line  on  the  scenario,  representing  a 
navigation  route  to  the  Brazilian  Naval  Academy,  as  shown  on  Figure  21.  The 
nautical  chart  was  made  available  for  this  demo,  representing  both  the  YP’s 
current  position,  and  heading  and  waypoints  along  the  route.  Using  the  flight 
yoke  controller,  the  players  were  able  to  control  the  ship’s  course  and  speed  over 
the  simulation,  while  checking  the  YP’s  indicators  on  screen. 


OO0OOO== 


Figure  21 .  YPSim  demo  at  the  2010  MOVES  open  house  event. 

The  general  impression  of  this  first  release  of  YPSim  was  very  positive, 
and  the  feedback  collected  was  of  great  value  to  improve  the  software.  The 
physical  model  was  not  yet  refined,  and  the  ship’s  response  to  the  commands 
were  not  realistic,  generating  important  observations  from  most  of  the  naval 
officers  who  drove  the  virtual  YP.  We  also  observed  that  some  lag  effects  were 
created  while  loading  the  BNA  3D  model,  whenever  it  became  visible  on  the 
screen.  Posterior  investigation  on  the  BNA  3D  model  led  to  an  optimization  on  its 
geometry,  significantly  reducing  its  file  size  and  loading  time.  Since  the  demoed 
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version  of  YPSim  was  not  overly  sophisticated,  only  basic  functionality  and 
training  concepts  were  tested,  but  with  great  results. 

B.  I/ITSEC  DEMO  RELEASE 

In  December  2010,  five  months  after  the  MOVES  open  house  release,  we 
demoed  YPSim  v0.5  at  the  exposition  floor  of  the  l/ITSEC  2010.  This  version  of 
YPSim  presented  significant  improvements  compared  to  the  previous  release, 
including  a  Graphical  User  Interface  (GUI),  a  helmsman  artificial  intelligence  (Al), 
radar  simulation,  and  refinements  on  the  physical  model.  An  important  bug  found 
on  the  ocean  model  was  also  removed,  making  the  simulation  more  stable  and 
robust.  YPSim  was  made  available  for  general  use  during  four  days  of 
conference  running  on  the  author’s  personal  laptop  computer  and  displayed  on  a 
50-inch  LCD  TV.  A  Playstation3™  controller  was  used  as  the  main  input  device 
for  controlling  the  YP. 


Figure  22.  YPSim  demo  at  the  l/ITSEC  2010. 

The  demo  attracted  approximately  one  hundred  users  during  the  four  days 
of  public  exposition  at  the  l/ITSEC,  almost  all  of  them  with  a  moderate  to  high 
level  of  expertise  on  the  training  simulation  field.  The  public  response  was,  again, 
surprisingly  positive,  with  good  questions  being  asked  about  YPSim 
implementation  concept  and  the  Delta3D  game  and  simulation  engine.  One  of 
the  most  interesting  questions  was  one  regarding  the  similarities  with  the 
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commercial  software  Ship  Simulator™,  developed  by  the  Dutch  company 
VSTEP.  Ship  Simulator,  the  commercial  game  described  in  Chapter  II,  is  a  very 
generic  application  that  provides  a  virtual  environment  of  a  civilian  boat  (i.e.,  tug 
boats,  transatlantic  ships,  cargo  ships,  water  taxi,  powerboats,  jet  skis)  and  a 
mission  that  is  not  related  to  the  instruction  of  shiphandling  skills  learned  at  naval 
academies  and,  therefore,  does  not  fit  our  needs.  In  order  to  do  that,  we  need  a 
game-based  simulation  that  has  a  very  specific  context,  simulating  the  YP,  doing 
the  same  type  of  missions  we  do  aboard  these  boats  (YPs).  A  brief  explanation 
of  the  task  analysis  conducted  in  Chapter  III  helped  users  to  understand  the 
conceptual  difference,  and  the  importance  of  having  a  game-based  simulator 
specifically  designed  for  the  midshipmen  world,  specially  in  the  military  scenario. 

C.  MOVES  OPEN  HOUSE  DEMO  RELEASE  (2011) 

Version  0.11  of  YPSim  was  released  during  the  2011  MOVES  open 
house,  in  July  201 1 .  This  version  contained  major  changes  in  the  physical  model 
of  the  YP,  significantly  improving  the  realism  of  the  ship’s  movements  and  the 
user’s  commands.  Mooring  lines  and  the  anchor  models  added  extra  functionality 
to  the  simulator,  allowing  users  to  moor/unmoor  the  YP  on  a  pier  and  also 
perform  anchoring  tasks.  The  feature  most  explored  during  this  demo  was  the 
scoring  system  and  the  Man  Overboard  (MOB)  mission  configuration,  where 
users  could  track  their  performance  on  a  score  ranking  system  updated  every 
trial.  This  feature  helped  to  attract  users  to  try  YPSim,  inducing  an  informal 
competition  between  them  in  order  to  put  a  name  at  the  top  of  the  rank. 

For  this  demo,  we  used  two  instances  of  YPSim  running  at  the  same  time 
in  different  desktops.  Each  station  was  using  a  regular  19-inch  LCD  monitor  with 
a  Ship  Driver™  controller  as  input  device.  This  two  instances  were  loading 
YPSim  from  a  local  server,  sharing  the  same  score  data  file,  which  was  used  to 
keep  track  of  the  top  ten  best  scores  on  the  MOB  mission  to  be  played.  Each 
player  started  the  MOB  mission  at  the  beginning  of  a  navigation  route  and,  as 
quickly  as  possible,  reached  a  final  waypoint  that  triggered  the  MOB  event.  The 
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player’s  score  was  calculated  using  the  time  to  accomplish  the  mission  and  offset 
from  the  navigation  route  as  performance  measures.  Upon  the  MOB  recover,  the 
score  was  calculated  and  compared  with  the  top  ten  rank  list,  displaying  the 
results  in  a  debriefing  menu.  If  the  score  was  good  enough,  it  was  placed  on  its 
rank  position  and  the  system  asked  for  player’s  name. 

The  improvements  on  the  YPSim  interface,  stability  and  physical  model 
refinements  generated  a  significantly  less  number  of  critics  and  better  reviews 
from  the  public,  giving  us  confidence  going  into  the  next  step  on  the  release 
process.  Only  a  few  minor  adjustments  appeared  critical  to  perform  before 
making  the  final  test  with  the  BNA  midshipmen. 

D.  FINAL  BNA  RELEASE 

The  final  release  of  the  prototype  version  of  YPSim  (v0.13)  was  made  on 
August  1,  2011.  This  was  the  most  critical  step  on  the  release  process,  now 
involving  the  software’s  final  user  population,  the  BNA  midshipmen.  This  would 
also  represent  the  first  impression  of  YPSim  to  the  academy’s  instructors  and 
officers,  who  are  familiar  with  the  real  BNA  YP,  the  simulated  platform.  Feedback 
from  this  release  was  collected  in  a  formal  survey  conducted  with  the 
midshipmen  during  a  two-week  trial  of  YPSim  running  in  a  lab.  The  lab  setup 
included  a  three-screen  (120-degree  horizontal  FOV)  display,  flight  yoke 
controller  and  the  use  as  a  team  (1  officer  of  the  deck,  1  helmsman,  1  lee- 
helmsman),  as  shown  in  Figure  23.  BNA  instructors  asked  for  a  configuration 
closer  to  the  real  YP  situation,  rather  than  a  game  approach,  which  led  to  YPSim 
running  on  a  first-person  view  mode,  inside  the  bridge,  almost  all  the  time. 

YPSim  version  0.13  was  tested  during  two  weeks  by  40  midshipmen  of 
the  2nd,  3rd  and  4th  grades.  These  midshipmen  were  volunteers  to  test  the 
simulator  and  all  had,  at  least,  initial  basic  classroom  instruction  of  navigation 
and  shiphandling.  Most  of  the  users  for  this  release  had  also  good  experience  on 
navigation  and  shiphandling  the  training  at  sea,  using  BNA  YPs.  Users  were  not 
required  to  have  any  proficiency  level  on  using  computer  and/or  games. 
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Experienced  BNA  instructors  and  YP  Commanding  Officers  were  also  invited  to 
freely  use  YPSim  in  this  release,  providing  valuable  feedback  to  improve  our 
design.  The  BNA  Superintendent  and  the  Dean  of  Education  actively  participated 
on  this  release,  demonstrating  great  institutional  support  to  our  research  efforts. 


The  results  of  BNA  and  midshipmen  and  instructors  exposure  to  YPSim 
were  incredibly  positive.  Both  sides  confirmed  the  potential  use  of  YPSim  in  the 
current  instructional  framework  for  navigation  and  shiphandling  topics  at  the 
BNA.  As  a  feedback,  we  were  able  to  collect  valuable  users’  critics  about  the 
graphics  quality,  interface  and  physics  model  that  pointed  some  weakness  of  the 
current  prototype.  After  the  release  of  version  0.13  at  the  BNA,  the  academy 
command  requested  to  keep  using  the  simulator  as  an  experimental  training 
resource  for  pre-sail  familiarization  before  the  YP  classes. 


Figure  23.  BNA  midshipmen  driving  the  virtual  YP  during  the  final 

release  of  YPSim. 
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VII.  USER  ACCEPTANCE  SURVEY 


We  conducted  a  formal  user  acceptance  survey  in  order  to  assess 
important  product  feedback  from  the  intended  user  population  of  YPSim.  After 
having  approved  the  IRB  process  to  conduct  a  survey  at  the  Brazilian  Naval 
Academy  (BNA),  we  released  the  final  prototype  version  of  YPSim  (version  0.13) 
to  a  sample  of  forty  volunteer  midshipmen.  A  navigation  and  shiphandling 
instructor  at  the  BNA,  who  is  also  a  former  Commanding  Officer  of  a  BNA  YP, 
integrated  our  research  team  and  conducted  this  survey  in  Brazil.  We  designed  a 
specific  survey  questionnaire  (Appendix  F)  to  collect  demographics  information 
and  midshipmen’s  opinions  of  the  current  BNA  learning  framework  and  YPSim 
usability.  This  chapter  describes  the  method  used  for  this  study  and  includes  a 
brief  analysis  of  the  results  found. 

A.  METHOD 

The  methodology  used  in  this  study  was  based  on  providing  controlled 
exposure  of  YPSim  to  a  sample  of  its  end  user  population  at  the  BNA  and 
collecting  their  reviews  in  a  user-acceptance  questionnaire,  after  the  using  the 
system. 

1.  Participants 

The  study  collected  data  from  a  sample  of  forty  volunteer  BNA 
midshipmen,  ranging  in  age  from  18  to  23  years.  All  participants  were  male, 
since  the  BNA  does  not  have  any  female  midshipmen.  We  asked  for  volunteers 
among  the  three  senior  grades  on  the  curriculum,  corresponding  to  the  2nd,  3rd 
and  4th  year  midshipmen  population. 

2.  Materials 

We  installed  YPSim  v0.13  on  a  desktop  with  the  following  hardware 
specifications: 
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•  CPU:  Intel  Xeon  2.53GHz 

•  Graphics  card:  NVidia  Quadra  FX  580  (512MB) 

•  RAM:  12GB 

•  Operating  system:  Windows  7™  64-bit 

A  Saitek®  Pro  Flight  Yoke  System  was  used  as  main  input  device  for 
YPSim,  while  three  50-inch  LCD  TVs  were  used  to  display  the  simulation, 
offering  120  degrees  of  horizontal  Field  of  View  (h-FOV)  to  the  users.  We  used  a 
Portuguese  translation  of  the  questionnaire  described  in  Appendix  F  to  conduct 
the  user  acceptance  survey.  The  system  demo  was  set  up  at  the  BNA 
shiphandling  and  navigation  lab. 

3.  Task 

Users  were  requested  to  use  YPSim  as  a  small  bridge  team,  playing  the 
roles  of  officer  of  the  deck  (OOD),  helmsman  and  lee-helmsman  in  a  basic 
navigation  mission.  A  fourth  midshipmen  was  asked  to  just  observe  the 
simulation  trial,  not  interfering  in  the  maneuver.  The  OOD  midshipman  was  in 
charge  of  handling  the  ship  along  a  given  navigation  route,  at  the  BNA 
surroundings,  providing  rudder  and  engine  orders  respectively  to  the  helmsman 
and  lee-helmsman  midshipmen.  At  the  end  of  the  navigation  route,  the  group 
was  allowed  to  freely  perform  MOB  and  mooring  tasks,  exploring  the  system 
functionalities. 

4.  Procedure 

The  forty  volunteer  midshipmen  were  randomly  divided  into  ten  groups  of 
four  and  requested  to,  as  a  group,  use  YPSim  for  a  single  50-minute  session. 
Trial  groups  were  randomly  scheduled  to  perform  the  YPSim  trial  in  a  70-minute 
block  at  the  afternoon,  after  regular  classes,  during  two  weeks  (one  group  per 
day).  Our  investigator  at  the  BNA  conducted  an  initial  10-minute  briefing  about 
the  YPSim  concept,  use  and  the  task  to  perform.  Participants  were  allowed  to 
ask  questions  at  any  time  during  the  briefing  and  trial  session. 


80 


After  the  briefing,  midshipmen  of  each  group  were  assigned  to  play  the 
four  roles  previously  described,  respecting  the  same  distribution  found  aboard 
the  YP.  Senior  midshipmen  were  assigned  to  OOD  and  observer  roles,  while  the 
junior  midshipmen  assumed  the  helm  and  engine  controls.  After  25  minutes  of 
trial,  OOD  and  observer  switch  roles,  allowing  both  of  them  to  actively 
experiment  YPSim.  During  the  trials,  YPSim  was  used  in  the  first-person  view 
mode,  from  inside  the  bridge.  After  using  the  simulator,  participants  were  asked 
to  fill  out  a  post-trial  questionnaire  and  were  then  dismissed. 

B.  RESULTS 

The  questionnaire  answers  are  summarized  in  Appendix  G.  We  made  an 
analysis  of  the  distribution  for  each  answer  obtained,  hoping  to  find  evidence  to 
support  some  assumptions  made  about  the  YP  system  and  YPSim’s  usability. 
Answers  for  the  Likert  scale  correspondence  range  from  1  to  disagree  with  the 
proposed  statement  and  5  to  a  full  agreement.  To  provide  a  general  picture  of  the 
results  observed  in  each  Likert  scale  question,  we  provided  a  bar  graph 
representing  their  average  answer.  However,  the  complete  understanding  of  end 
user  trend  should  be  inferred  from  the  distribution  plot,  since  the  average  can 
mask  important  patterns  in  the  response,  such  as  mode  and  distribution. 

1.  Demographics 

Among  the  40  participants,  15  were  from  the  2nd  year,  thirteen  from  3rd 
year,  and  twelve  from  4th  year  grades  on  the  BNA  midshipmen  rank.  Only  12.5% 
of  them  had  collateral  duties  as  navigation  and  shiphandling  mentors  aboard  the 
YPs.  The  proportion  of  reported  gamers  found  was  37.5% — less  than  expected 
given  other  surveys  made  in  the  U.S.  for  the  same  age  range  in  the  military 
community.  Only  15%  of  the  participants  reported  having  previously  played  any 
ship  simulator  type  of  game,  indicating  that  the  user  population  is  not  extremely 
familiar  with  this  type  of  technology. 
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2. 


YP  Learning  Framework 


Supporting  our  initial  assumptions  that  midshipmen  require  a  significant 
amount  of  familiarization  time  during  the  hands-on  training  aboard  the  YP,  97.5% 
of  the  participants  answered  that  they  required  between  10  and  60  minutes  to  get 
used  to  the  task.  Although  this  is  a  high  percentage  of  the  sample  population,  the 
mode  of  this  distribution  was  between  10  and  30  minutes  (67.5%),  considered 
lower  than  the  expected  mode  (between  30  and  60  minutes).  The  preferred 
learning  method  used  by  the  midshipmen  aboard  was  largely  divided  between 
observe  and  comfortable  to  ask  questions  and  doing  by  himself  (40%)  and  not 
afraid  to  fail  (42.5%).  This  distribution  shows  that  midshipmen,  in  general,  feel 
free  to  interact  with  the  system,  asking  questions  and  not  afraid  to  make 
mistakes. 

* - 

Question 

Disagree 

-j  a  I  feel  confident  that  my  knowledge  about  the  tasks 
/M  executed  aboard  will  be  sufficient. 

~j  d  Before  going  aboard,  I  have  complete  understanding  of  the  tasks  I'll 
execute 

7C  YP  hands  on  training  motivates  me 

YP  hands  on  training  is  important  to  learn  navigation  and  ship  handling 
/u  skills 

7E  I  feel  well  prepared  every  time  I  go  aboard  the  YP  for  training 

-jr  There  is  some  knowledge  gap  between  classroom  theory  and  the 
' '  practice  aboard  the  YP 

The  number  of  YP  training  sessions  is  enough  to  understand  the 
'  ^  theory  and  master  the  skills  of  navigation  and  ship  handling 

Sometimes  I  want  to  execute  (or  repeat)  a  maneuver  onboard  but 
/H  there  is  not  enough  time  to  do  that 


Figure  24.  Mean  response  diagram  for  questions  about  the  current 

learning  framework. 


mean  response 
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Questions  about  the  midshipmen’s  opinion  of  the  YP  framework  revealed 
that  their  confidence  over  having  enough  previous  theoretical  knowledge  is  not 
very  high.  With  a  similar  distribution,  midshipmen  reported  not  having  total 
previous  understanding  of  the  tasks  to  be  conducted  in  a  hands-on  training 
aboard  the  YP  (question  7B,  mean  3.3  and  mode  4  with  40%).  When  considering 
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the  YP  training  as  a  motivational  activity,  most  of  the  participants  agreed,  in 
some  degree,  with  the  statement  (question  7C,  mean  3.9  and  mode  5  with  35%). 
The  numbers  proved  that  midshipmen  believe  YP  training  is  an  important  step  in 
learning  navigation  and  shiphandling  (question  7D,  mean  4.8  and  mode  5  with 
80%).  In  general,  the  midshipmen  do  not  feel  confidently  prepared  for  the  YP 
training  events  (question  7E,  mean  3.7  and  mode  4  with  40%)  and  57%  of  the 
participants  fully  agreed  with  the  presence  of  a  knowledge  gap  between 
classroom  theory  and  practice  aboard.  Evidence  that  the  current  number  of 
hands-on  training  sessions  is  not  enough  is  suggested  given,  the  distribution 
found  for  this  question  (question  7G,  mean  3.5  and  mode  4  with  45%).  The 
answer  distribution  also  supports  the  assumption  that  midshipmen,  in  general, 
would  like  to  have  more  maneuvering  opportunities,  restricted  by  the  time 
(question  7H,  42.5%  of  fully  agreement). 

3.  Use  of  a  Simulator  for  Training 

Most  of  the  participants  agreed  to  some  degree  that  the  use  of  a  ship¬ 
driving  simulator  would  help  to  reduce  any  knowledge  gap  between  classroom 
and  hands-on  training  (question  8A,  mean  4.1  and  modes  4  and  5  with  both 
37.5%).  About  the  use  of  a  ship-driving  simulator  being  motivational  to  the  body 
of  students,  80%  fully  agreed  with  this  statement.  This  is  extremely  relevant  to 
support  the  assumption  that  the  user  population  is  prone  to  accept  this  type  of 
technology.  The  use  of  a  ship-driving  game  simulator  before  the  aboard  tasks  on 
the  YP  was  fully  supported  by  75%  of  the  participants.  For  the  statement  that  a 
YP  simulator  is  not  important  and  will  never  help  to  improve  performance,  90%  of 
the  participants  fully  disagreed  with  this  idea.  Most  of  the  midshipmen  (82.5%) 
considered  the  use  of  a  YP  simulator  as  a  valuable  instructional  resource  inside 
a  classroom,  providing  a  better  understanding  of  the  theory. 
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Question 


The  use  of  a  ship  driving  simulator  would  help  me  to  reduce  any  knowledge  gap 
8A  between  classroom  and  the  hands  on  training 


gg  The  use  of  a  ship  driving  simulator  would  be  a  motivational  tool  to  academy's 
midshipmen 


8C 


If  I  had  a  ship  driving  game  simulator  in  which  I  was  able  to  play  the  same  tasks 
executed  aboard  the  YP,  I  would  use  it  to  practice  before  going  aboard 


8D  AYP  simulator  is  NOT  important  and  will  never  help  me  to  perform  better  aboard 
the  YP 

op  The  use  of  a  YP  simulator  would  be  a  valuable  instructional  resource  inside  the 
classroom,  making  it  easier  to  better  understand  procedures  and  maneuvers 


mean  response 

Disagree  Neutral  Agree 


4.1 

4.7 

4.6 

i— 

1.1 

4.7 

0.0  2.5  5.0 


Figure  25.  Mean  response  diagram  of  questions  about  the  use  of 

simulators  for  training. 


4.  YPSim  Usability 

The  initial  impression  of  the  participants  about  the  graphic  quality  of 
YPSim  was  good  (question  8F,  mean  4.0  and  mode  5  with  47.5%)  even  though 
the  trialed  version  was  only  a  prototype  without  refinements  on  the  3D  models 
used.  When  asked  about  YPSim  being  a  valuable  training  tool,  most  of  the 
participants  (62.5%)  agreed  with  the  statement.  The  present  sensation  of  YPSim 
did  not  score  well  among  the  midshipmen,  and  the  distribution  for  this  statement 
was  evenly  spread  without  a  significant  mode  on  the  level  of  agreement.  When 
asked  about  playing  YPSim  on  their  own  PCs,  if  available,  participants  agreed 
with  the  statement  (question  81,  mean  4.0  and  mode  5  with  40%).  Although  this 
was  a  good  indicator,  the  distribution  was  less  positive  than  expected  when 
compared  with  answers  found  for  a  previous  similar  question  (8C)  regarding  the 
personal  use  of  a  ship-driving  simulator. 
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Question 


Disagree 


mean  response 

Neutral 


Agree 


8F  YPSim  graphics  quality  is  good 

8G  YPSim  can  be  a  valuable  training  tool 

8H  Using  YPSim  gives  me  the  sensation  of  being  onboard  the  YP 


8|  If  I  had  a  version  of  YPSim  in  my  PC  I  would  play  it 

8J  The  YP's  movements  and  physics  response  in  YPSim  are  close  to  the  reality 

YPSim  indicators  are  easy  to  read  and  give  the  user  a  complete  understand  about  the 
YP  situation 


q  .  All  information  needed  (controls,  sensores,  visualization,  sound,...)  to  execute  the 
OL  tasks  are  available  on  YPSim 

The  use  of  YPSim  can  motivate  midshipmen  and  make  them  feel  closer  to  the  future 
8M  job  aboard  a  real  ship 


8N 


Using  YPSim  will  be  a  waste  of  time,  no  simulation  can  replace  the  hands  on  training 


aboard  the  YP 

„ YPSim  has  poor  quality  and  is  too  distant  from  a  good  simulators  that  could  be  used 
as  a  valid  training  tool 


Figure  26.  Mean  response  diagram  of  questions  specifically  about 

YPSim  usability. 


The  level  of  agreement  with  the  realism  of  the  YP’s  physical  model  in 
YPSim  was  moderately  good  (question  8J,  mean  3.6  and  mode  4  with  45%),  with 
similar  distributions  to  the  interface  quality  questions  8K  and  8L  (means  3.9  and 
3.8,  mode  4  with  47.5%  and  60%,  respectively).  Most  of  the  participants  fully 
agreed  with  potential  of  YPSim  as  a  motivational  asset  to  their  careers  (question 
8M,  mean  4.4  and  mode  5  with  67.5%).  With  almost  the  same  reverse 
distribution,  the  use  of  YPSim  was  not  considered  a  complete  waste  of  time  by 
67.5%  of  the  participants.  When  compared  to  other  simulators  that  participants 
could  have  in  mind,  YPSim  was  evaluated  as  not  too  distant  to  other 
technologies  (question  80,  mean  2.2  and  mode  2  with  37.5%). 

5.  Open-Ended  Questions 

From  the  sample  of  forty  participants,  only  23  answered  the  open-ended 
questions  requesting  comments  and  suggestions  to  improve  YPSim.  The 
answers  provided  valuable  feedback  about  the  user’s  opinion  of  the  simulator, 
providing  good  insights  into  future  steps  for  implementing  it  as  a  training  tool  at 
the  BNA  learning  framework.  About  six  participants  suggested  the  importance  of 


85 


having  YPSim  freely  distributed  among  the  midshipmen  body  of  students  for  use 
on  their  personal  PCs.  Other  participants’  responses  reinforced  the  motivational 
aspect  of  using  YPSim  as  a  training  tool,  more  specifically  to  the  freshmen 
midshipman  of  the  1st  and  2nd  years,  complementing  the  initial  basic 
professional  courses  of  the  BNA.  In  general,  participants  who  responded  the 
open-ended  questions  demonstrated  enthusiasm  with  the  application  and  were 
excited  about  using  it  in  the  near  future.  One  midshipman  suggested  the 
implementation  of  other  classes  of  ships  in  YPSim,  while  another  two 
recommended  the  integration  with  the  BNA’s  tactical  simulator  used  for  other 
disciplines.  There  was  only  one  critical  review  coming  from  the  open-ended 
questions  and  it  regarded  the  use  of  a  PC  game  for  a  team  task  trainer.  This 
participant  asked  the  question  how  YPSim  could  be  used  on  individual  PCs  to 
train  in  a  teamwork  situation,  considering  the  OOD,  helmsman  and  lee- 
helmsman. 

C.  ANALYSIS 

We  evaluated  the  overall  results  of  the  survey  as  extremely  positive  for  the 
scope  of  this  research.  The  results  showed  us  important  evidence  of  a  user 
population  that  has  a  moderate  proportion  of  gamers  and  a  large  proportion  of 
believers  in  the  value  of  the  virtual  environment  simulation  technology.  YPs  are 
believed  to  provide  valuable  training  to  the  BNA  midshipmen.  The  current 
learning  framework  presents  significant  knowledge  gaps,  which  could  be 
addressed  using  a  ship-driving  simulator  to  increase  familiarization  and 
performance  aboard. 

There  is  enough  evidence  to  support  the  relevance  of  a  ship-driving 
simulator  in  improving  the  training  experience  among  the  midshipmen  population. 
Using  a  simulator  as  an  instructional  tool  could  also  represent  a  good 
contribution  to  improve  midshipmen  understanding  of  such  complex  topics.  By 
modeling  other  types  of  ships  that  could  represent  midshipmen’s  near  future  as 
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an  officer,  the  motivational  level  of  the  students  could  increase,  representing 
more  knowledge  absorption  inside  the  classroom. 

The  analysis  of  YPSim’s  usability  brings  important  insights  into  how  the 
user  population  sees  this  type  of  technology  attached  to  the  game  industry.  For  a 
generation  raised  on  video  games,  expectations  for  graphics  and  speed  are  high. 
Therefore,  the  relatively  moderate  acceptance  of  the  interface  quality  and 
physics  model  may  be  a  reflection  of  the  student’s  history  with  video  games.  The 
results  are  extremely  relevant  and  indicate  that  product  improvements  are 
needed,  regarding  the  graphics,  interface  and  physical  model  of  the  YP.  When 
considered  the  current  version  of  YPSim  as  a  prototype,  made  without  the  help  of 
any  professional  3D  artist  or  programmer,  we  could  see  a  positive  user 
acceptance  evaluation. 

The  user  population  is  motivated  over  the  technology  and  concept  of 
YPSim,  meaning  that  their  minds  are  opened  to  use  it.  The  possibility  of 
distributing  YPSim  for  personal  use  on  midshipmen’s  PCs  should  be  considered 
as  an  important  step  in  order  to  reduce  the  knowledge  gap  and  increase  YP 
familiarization.  Although,  this  step  must  be  conducted  only  after  the  product 
refinements  previously  mentioned  in  order  to  increase  acceptance.  Further 
research  must  be  conducted  in  order  to  gather  more  precise  information  about 
the  issues  affecting  presence  and  usability  in  precise  terms,  enabling  the  specific 
product  improvements. 


87 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


88 


VIII.  CONCLUSION  AND  FUTURE  WORK 


A.  CONCLUSION 

Using  the  Brazilian  Naval  Academy  (BNA)  environment  as  a  case  study 
scenario,  we  were  able  to  study  the  tasks  trained  aboard  naval  academy  yard 
patrol  (YP)  craft.  The  cognitive  process  involved  in  learning  navigation  and 
shiphandling  material  set  the  correct  path  towards  the  development  of  a  game- 
based  simulation  tool,  intended  to  reduce  the  knowledge  gap  between  classroom 
and  aboard  instruction.  At  the  end  of  our  research,  a  proof  of  concept  product, 
called  YPSim,  became  available  for  midshipmen  use  at  the  BNA  at  a  low  cost  by 
using  the  Delta3D  open  source  simulation  game  engine. 

We  presented  YPSim  to  the  public  at  the  l/ITSEC  201 1  ground  floor  and 
received  impressive  reviews  about  the  concept  adopted  in  the  simulator  and 
research  results  for  the  version  presented.  At  the  BNA,  YPSim  was  originally 
introduced  for  study  purposes,  however,  the  great  acceptance  level,  from  both 
midshipmen  and  instructors,  made  the  President  to  adopt  the  simulator  in  the 
current  training  framework.  Instructors  aboard  the  YPs  reported  significant 
improvements  in  midshipmen  performance  at  sea,  after  the  use  of  YPSim  at  BNA 
as  a  pre-sail  familiarization  training.  Our  project  also  caught  attention  form  other 
two  full  mission  bridge  simulator  projects  at  the  Brazilian  Navy,  one  under 
development  at  the  University  of  Sao  Paulo  (USP)  for  the  Fleet  Training  Center, 
and  another  by  the  Center  for  Naval  Systems  Analysis  (CASNAV)  and 
Fluminense  Federal  University  (UFF)  for  the  Merchant  Marine  Academy.  These 
two  projects  present  several  similarities  with  YPSim  that  could  be  reused  in  their 
design  and  development,  representing  a  practical  application  of  our  research. 

We  proposed  the  integration  of  YPSim  with  a  open  source  research 

project  for  Command  and  Control  under  development  at  the  Pontifical  Catholic 

University  of  Rio  de  Janeiro  (PUC-Rio).  This  work,  titled  A  Game  System 

Approach  for  Training  and  Evaluation:  Two  sides  of  the  same  coin,  became 
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published  in  the  Proceedings  of  European  Conference  on  Simulation  and  Al  in 
Computer  Games  -  GAMEON'1 1  (Moraes,  2011).  In  this  paper,  we  presented  an 
integration  framework  between  YPSim  and  the  Command  and  Control  System 
(CSS)  to  provide  real  time  feedback  of  a  training  exercise  at  sea  to  an  instructor 
inside  a  classroom. 

YPSim  was  tested  and  refined  along  these  two  years  of  research  efforts, 
now  representing  a  current  training  tool  for  the  BNA  midshipmen.  Results  of  our 
user  acceptance  survey  were  used  to  support  the  BNA  superintendent’s  decision 
of  adopting  the  current  version  of  YPSim  for  midshipmen  training.  We  understand 
that  this  concept  of  an  easily  accessible  simulation  for  ship-driving  basic  training 
at  naval  academies  has  great  potential;  although,  a  future  training  transfer 
research  is  still  required.  The  use  of  this  technology  by  other  institutions,  rather 
than  BNA,  can  be  achieved  by  minor  changes  in  the  current  design  and  3D 
models. 

B.  FUTURE  WORK 

The  current  version  of  YPSim  was  developed  only  for  proof-of-concept 
purposes  and  has  many  limitations  before  being  considered  a  product  that  is 
ready  to  be  used.  Future  research  should  be  focused  on: 

•  Artificial  Intelligence  (Al)  agents  for  realistic  ship  control  on  the 
scenario,  more  specifically  for  tactical  maneuvers  missions 

•  Al  agents  for  realistic  representation  of  the  boatswain,  helmsman, 
lee-helmsman  and  navigator  roles 

•  Intelligent  tutoring  system  using  an  Al  agent 

•  More  refined  3D  models 

•  More  refined  YP  physical  mode 

•  Graphical  user  interface  (GUI)  improvements 

•  Missions  tutorials  implementation 

•  Code  optimization  for  better  runtime  performance  using  inferior 
hardware  requirements 

•  HLA/DIS  network  compatibility 

•  After  Action  Review  (AAR)  capability 
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The  user  acceptance  survey  results  indicate  that  YPSim  has  a  great 
adoption  potential  among  the  midshipmen  population,  however,  a  future  training 
transfer  study  is  still  necessary  to  understand  the  true  effectiveness  of  this  tool. 
We  hope  that  future  students  find  YPSim  useful  as  a  research  platform  in  the 
arena  of  simulation  for  training. 


Figure  27.  BNA’s  Superintendent — Rear  Admiral  Leonardo  Puntel, 

on  left — briefing  YPSim  to  a  group  of  retired  General  Officers 
visiting  the  naval  academy. 
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APPENDIX  A.  3D  MODELS 


X3D  Editor  was  used  only  for  initial  3D  mesh  creation  of  the  Brazilian 
Naval  Academy’s  (BNA)  YP  model  at  the  very  initial  stage  of  the  research.  Since 
X3D  Editor  does  not  provide  support  to  OSG  special  nodes  functionality,  which 
was  required  to  YPSim,  the  initial  BNA’s  YP  model  created  in  X3D  was  exported 
to  a  file  format  supported  in  3D  Studio  Max.  Later  developments  in  the  BNA’s  YP 
model  were  done  using  3D  Studio  Max  and  the  OSG  plugins  available  at  the 
time,  allowing  OSG  node  insertion  and  .osg/.ive  exporting  features. 

The  initial  option  for  using  Blender,  an  open  source  3D  editing  software 
(Salvatore,  2005),  did  not  last  long.  OSG  plugins  available  for  Blender  at  the  time 
allowed  only  export/import  functionality  into  OSG  supported  formats  (.osg/.ive), 
and  special  nodes  features  must  be  implemented  using  another  tool  called 
OSGEdit.  These  special  nodes  can  be  defined  as  scene  graph  points  accessible 
by  the  application  allowing  special  manipulation  and  control  of  the  3D  model 
state.  YPSim  uses  the  following  special  nodes  in  its  3D  models: 

•  Degrees  Of  Freedom  (DOF),  allowing  runtime  manipulations  of 
geometry’s  rotation  inside  the  model.  This  node  allows,  for 
instance,  YPSim  to  rotate  the  YP’s  Radar  antenna  at  any  given 
speed,  simply  by  coding  changes  in  this  node’s  Heading  Pitch  Roll 
(HPR)  values. 

•  Switch,  allowing  runtime  manipulation  of  the  displayed  geometry  for 
a  given  part  of  the  3D  model.  This  node  can  be  used  to  hold 
different  3D  geometries  representing  the  states  of  a  light  bulb  on  a 
buoy  (on/off).  YPSim  code  can  access  this  node  inside  the  buoy’s 
model  and  selecting  which  light  bulb  to  display  on  the  scene. 

•  Level  Of  Detail  (LOD),  allowing  runtime  selection  of  which  model 
geometry  to  be  rendered  on  the  scene,  based  on  the  distance 
between  the  model  and  scene’s  camera.  This  node  is  mostly  used 
to  optimize  the  number  of  polygons  on  the  scene,  rendering  less 
refined  geometries  that  are  too  far  from  the  camera. 

To  facilitate  the  use  of  this  important  OSG  functionality  in  a  single  editing 
tool,  the  author  purchased  a  student  license  of  3D  Studio  Max,  which  was  used 
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in  this  research  project.  3D  Studio  Max  offered  more  scene  management 
functionality  for  complex  models  required  in  this  project,  although  the  same 
results  could  be  achieved  using  the  open  source  tools  Blender  and  OSGEdit. 

1.  YP  3D  Model 


According  to  the  requirements  of  YPSim,  the  geometries  on  the  scene 
shall  provide  a  fair  amount  of  immersion  to  the  user.  The  user’s  YP  is  the  most 
important  3D  mesh  present  on  the  scene  and  must  contain  a  reasonable  level  of 
details  in  order  to  provide  the  necessary  visual  cues  to  the  player’s  cognitive 
process  during  the  mission  execution.  Three  different  YP  3D  models  were 
created  on  3D  Studio  Max  for  YPSim.  Each  model  represents  a  real  Brazilian 
Naval  Academy  YP  with  hull  numbers  U10,  U11  and  U12.  The  models  have  the 
exact  same  geometries  and  nodes,  but  with  different  textures  representing 
individual  names,  numbers,  call  sign,  and  crest. 


Figure  28.  The  YP  U1 1  being  edited  in  3D  Studio  Max  -  Educational 

Edition. 
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The  YP  3D  model  has  special  features  that  make  it  different  from  other 
models  on  YPSim.  Several  OSG  Special  nodes  were  used  to  allow  special 
runtime  manipulations  into  YP’s  geometry  by  YPSim  application.  These  nodes 
manipulation  are  important  to  present  a  fairly  good  level  of  detail  and  realism 
required  for  some  of  the  visual  cues  needed.  Thanks  to  the  DOFTransform  OSG 
node,  YPSim  is  able  to  access  and  control  rotation  parameters  of  several  key 
geometries  inside  the  YP  3D  model,  generating  nice  simulation  effects. 

The  DOFTransform  nodes,  like  any  other  OSG  special  node,  are  not 
rendered  into  the  scene,  keeping  it  invisible  to  the  user.  Special  nodes  are  visible 
only  at  the  editing  tool,  and  represented  by  3D  Studio  Max  as  blue  3D  axis 
(Figures  28  and  29).  Figure  29  presents  the  geometries  inside  the  model  that  are 
child  of  a  DOFTransform  node,  allowing  the  transform  manipulations  at  runtime. 
Navigation  lights  can  be  manipulated  using  a  Switch  node,  toggling  it  on/off 
(Figure  29A).  Wind  birds  for  the  anemometers  can  be  pointed  to  the  apparent 
wind  and  span  proportionally  to  wind  speed  (Figure  29B).  Propeller  and  rudder 
movements  can  be  simulated  by  correspondent  DOFTransform  parent  nodes, 
providing  a  nice  visualization  of  the  underwater  situation  (Figure  29D).  Inside  the 
bridge,  important  moving  parts  will  provide  valuable  visual  cues  during  the 
maneuvers,  such  as  engine  control  levers,  gyro  compass  dial,  helm,  and  rudder 
indicator  needle  (Figure  29E).  Even  though  YP’s  .50  caliber  machine  gun  is  not 
covered  by  the  YPSim  requirements,  DOFTransform  nodes  were  implemented  in 
order  to  provide  a  motivational  functionality  to  the  youth  population  of  users 
(Figure  29E). 

The  YP  3D  model  also  contains  DOFTransform  nodes  for  each  one  of  the 
nine  mooring  lines  on  the  BNA  YPs.  These  nodes  and  the  corresponding 
geometries  for  the  mooring  lines  are  not  visible  in  Figures  16  and  17;  further 
details  about  this  feature  are  given  in  Chapter  III,  C. 


95 


Figure  29.  Detailed  parts  of  the  YP  3D  geometry,  containing  OSG 

special  nodes. 


2.  Terrain 

YPSim  has  the  Guanabara  Bay  (Rio  de  Janeiro  -  Brazil)  as  its  basic 
scenario,  since  this  represents  the  Brazilian  Naval  Academy’s  surroundings  and 
most  common  training  environment  for  the  BNA  YPs.  Due  to  time  constraints  and 
for  the  scope  of  this  thesis,  only  three  mission  environments  were  developed. 
The  first  contains  the  Brazilian  Naval  Academy  (Guanabara  Bay),  the  second  a 
small  set  of  fictitious  islands  in  the  middle  of  the  ocean,  and  a  third  one  with  no 
terrain,  representing  Open  Ocean. 
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Figure  30.  3D  models  of  the  Guanabara  Bay  (top)  and  Brazilian 

Naval  Academy  (bottom). 


The  Guanabara  Bay  terrain  was  created  at  the  Laboratories  de  Sistemas 

Digitais  (LSI)  of  the  University  of  Sao  Paulo  -  Brazil,  as  part  of  another  virtual 

environment  simulator  project  under  development  for  the  Brazilian  Navy 

(Rodrigues,  2010).  The  original  model  was  created  using  Maya  editing  tool  and 

converted  to  3D  Studio  Max  by  the  author.  An  extensive  editing  process  took 

place  in  order  to  adapt  LSI’s  original  model  into  the  actual  YPSim  main  terrain 

file.  Using  Level  Of  Detail  (LOD)  nodes  and  mesh  optimization  to  reduce  the 

number  polygons,  the  model  became  light  enough  to  run  in  conventional  PCs.  A 
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separated  model  for  the  Brazilian  Naval  Academy  buildings  was  created  by  the 
author  and  added  on  top  of  the  basic  terrain.  This  step  was  necessary,  given  the 
refinements  required  for  this  specific  location,  used  for  referencing  in  most  of  the 
maneuvers  on  YPSim.  The  most  important  landmarks  and  geographic  features, 
such  as  lighthouses,  buildings,  hills  and  coastlines,  are  represented  and  correctly 
positioned  in  the  terrain. 

The  second  terrain  file  is  a  simple  set  of  two  fictitious  islands  created  by 
the  author  in  order  to  provide  YPSim  with  a  lighter  scenario  for  better 
performance,  since  it  has  significantly  less  polygons  than  Guanabara  Bay. 

3.  Other  Scene  Objects 

In  order  to  have  more  detailed  scenarios,  YPSim  also  uses  separate  3D 
models  for  navigation  buoys,  other  surface  contacts  and  to  represent  piers  used 
for  mooring. 

The  navigation  buoys  use  LOD  nodes  to  performance  optimization  and 
Switch  nodes  to  control  light  state  (on/off).  The  geometries  used  for  the 
navigation  buoy  follow  the  standard  buoy  formats  adopted  in  Brazil,  providing  a 
realistic  representation  of  this  important  navigation  aid.  A  total  of  11  types  of 
navigation  buoys  were  created  for  YPSim  and  seven  of  them  use  LOD  nodes  in 
three  levels,  (a)  high  definition  for  distances  between  0  and  800  meters,  (b) 
medium  resolution,  between  800  and  3,000  meters,  and  (c)  low  resolution,  used 
at  distances  greater  than  3,000  meters  (Figure  31 ). 
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Figure  31 .  Examples  of  the  3D  models  used  for  buoys. 

Surface  contacts  that  compose  the  scenario  use  very  simple  3D  models 
that  contain  no  OSG  special  nodes.  Figure  32  presents  some  examples  of  the 
models  used  in  YPSim  to  simulate  the  typical  surface  contacts  expected  at  the 
Guanabara  Bay  scenario  environment.  Navy  warships  transiting  to  or  from  the 
naval  base  are  frequently  observed  at  the  BNA’s  surroundings,  bringing  an 
important  motivational  aspect  to  the  midshipmen  aboard  the  YP  (Figure  32A). 
Merchant  ships,  fishing  and  sailing  boats  represent  an  important  component  in 
the  scenario,  significantly  increasing  the  Officer  of  the  Deck’s  (OOD)  cognitive 
processing. 


Figure  32.  3D  models  of  the  surface  contacts  used  in  YPSim. 
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Piers  used  for  mooring  require  special  OSG  nodes  (Group)  for  YPSim 
access  during  runtime.  Accessing  this  nodes  transform  matrices;  the  code  is  able 
to  calculate  the  position  of  each  pier  bollard,  which  is  important  for  mooring. 
Figure  33  shows  the  two  pier  models  used  on  YPSim.  The  first  is  fictitious  and 
included  at  the  Islands  scenario  (A),  while  the  second  is  an  exact  representation 
of  the  one  used  at  the  BNAs  (B).  The  correct  position  of  each  bollard  and  the 
fenders  have  extreme  relevance  for  the  simulation  of  a  real-world  mooring 
scenario,  such  as  the  BNA. 
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Figure  33.  3D  models  representing  the  piers  used  for  mooring. 
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APPENDIX  B.  MOORING  LINES  IMPLEMENTATION 


The  mooring  lines  simulation  is  composed  of  two  parts:  visual  and 
physics.  The  YP  has  10  lines  available  on  the  deck,  one  centered  at  the  bow, 
one  centered  at  the  stern  and  four  more  each  side  of  the  YP.  Bollards  placed  on 
the  deck  mark  the  place  where  YP’s  crew  handles  the  mooring  line.  At  the  other 
extreme  of  each  line  is  another  bollard,  located  at  the  pier.  For  each  simulated 
line,  a  relative  force  is  applied  on  the  YP’s  body  at  the  corresponding  bollard  on 
deck.  The  relative  force  vector’s  direction  is  given  by  the  pier  and  deck  bollard’s 
alignment,  and  its  magnitude  is  proportional  to  the  difference  of  the  line  length 
and  the  distance  between  bollards,  as  shown  in  Figure  34. 


Figure  34.  Screenshot  of  a  YPSim  mooring  maneuver  showing  the 

components  used  in  the  model 

Each  mooring  line  is  composed  by  six  cylinders  and  DOFTransform  pairs 
in  a  parent  child  chain.  The  higher  pair  in  the  chain  is  the  one  closer  to  the 
associated  YP’s  bollard.  Each  cylinder  has  one  meter  in  length  and  is  rendered  in 
white  in  the  scene.  Cylinders  are  represented  with  different  colors  in  Figure  35  for 
better  visualization. 
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Figure  35.  Screenshot  of  the  3D  editing  tool  showing  the 

DOFTransform  nodes  and  geometries  of  the  mooring  lines, 
incorporated  to  the  YP’s  3D  model. 


In  a  mooring  mission  in  YPSim,  the  player  can  activate  or  deactivate  each 
line  by  pressing  special  keys  on  the  selected  input  device.  The  current  version  of 
YPSim  does  not  allow  the  user  to  select  which  bollard  at  the  pier  to  put  the  line. 
For  the  scope  of  this  thesis,  each  line  has  its  predefined  pier  bollard  position 
corresponding  to  the  typical  mooring  at  the  BNA  pier.  At  the  activation,  the 
distance  between  bollards  (pier  and  YP)  is  stored,  representing  the  initial  line 
length.  Each  DOFTransform  is  rotated  towards  the  pier  bollard  and  scaled  to 
increase  cylinder’s  length  in  order  to  match  the  total  line  length.  A  relative  spring 
force  is  calculated  at  every  physics  step,  using  a  vector  with  direction  equivalent 
to  the  vector  formed  between  the  two  bollards.  The  magnitude  of  the  force  will 
follow  a  spring  model,  using  a  given  constant  and  the  square  of  the  difference 
between  the  actual  inter-bollard  distance  and  the  stored  line  length.  If  this 
difference  is  negative,  meaning  the  line  is  not  under  tension,  no  force  is  applied. 
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Figure  36.  Visualization  of  the  rendering  effects  simulating  tensioned 

and  slacked  lines 

The  DOFTransform  nodes  for  each  cylinder  are  used  to  scale  the 
cylinders  to  perfectly  match  the  total  line  length.  If  the  line  is  tensioned, 
separation  between  lines  will  appear,  providing  an  important  visual  cue  to  the 
player  in  order  to  assess  how  tight  the  line  is.  In  case  of  a  slack  line,  the  total 
length  of  the  line  is  respected  and  the  rendered  effect  of  an  arc  is  obtained  by 
reorienting  each  DOFTransform  in  a  systematic  way.  The  arc  effect  is  another 
important  visual  cue  about  the  tensioning  state  of  the  mooring  line.  The  final 
rendering  effects  can  be  visualized  in  Figure  36. 

Special  commands  are  available  to  the  user,  allowing  the  lines  to  be 
thrown  off  and  to  heave  it,  adjusting  the  stored  length  to  the  current  inter-bollard 
distance.  For  the  scope  of  this  thesis,  a  specific  interactive  GUI  for  controlling  the 
mooring  lines  was  not  implemented  on  the  current  version  of  YPSim.  Methods  for 
improving  the  mooring  line  functionality  are  encouraged  in  future  research. 
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APPENDIX  C.  ANCHOR  IMPLEMENTATION 


The  anchor  model  developed  in  this  work  is  simple  and  takes  into  account 
only  the  most  important  factors  to  simulate  the  process  of  dropping  and  setting 
the  YP’s  anchor.  The  model  is  composed  of  several  objects  of  the  dtCore:: Object 
class,  with  their  physics  enabled.  The  chain  is  made  of  several  sections  and  each 
section  is  simulated  as  a  separate  physical  object  (dtCore: :Object).  Chain 
sections  are  linked  using  an  ODE  ball  socket  joint  (ODE,  n.d.),  allowing  only  free 
angular  movement  between  bodies.  The  first  chain  section  is  attached  to  the 
YP’s  body  at  the  hawse  pipe.  The  anchor  is  made  of  two  distinct  bodies,  one 
representing  the  anchor  shank  and  the  other  grouping  crown,  stock  and  flukes. 
The  last  chain  section  is  connected  to  the  shank  using  a  ball  socket  joint  and  the 
shank  is  attached  to  the  crown  via  a  hinge  joint,  with  high  and  low  angle  limits 
simulating  shank  movement  restrictions.  The  lower  body  of  the  anchor, 
composed  of  crown,  stock  and  flukes,  has  five  contact  joints  to  create  friction 
against  the  seabed.  Figure  37  graphically  describes  the  chain  sections  and 
anchor  with  respective  joints.  In  this  case,  only  six  chain  sections  were  used  in 
the  model;  however,  this  value  is  configurable  in  the  scenario  mission  file.  The 
recommended  CPU  configuration  for  YPSim  can  handle  up  to  40  sections 
without  significant  loss  of  performance,  increasing  the  refinement  of  the 
simulation. 

To  simulate  the  complexity  of  setting  the  anchor,  dynamic  values  of  mass 
are  calculated  for  the  anchor’s  lower  body.  In  real  life,  the  pulling  force  applied  to 
the  anchor  should  be  as  horizontal  as  possible  in  order  to  get  more  friction  from 
the  flukes.  If  the  chain  length  is  not  long  enough,  the  pulling  force  will  start  to 
have  a  vertical  component,  pulling  the  anchor  upwards  and  reducing  friction.  In 
this  model,  the  friction  coefficients  applied  at  each  one  of  the  contact  points  are 
constant;  however,  if  the  anchor  is  tilted  and  not  horizontally  laid  on  the  seabed, 
fewer  contact  points  will  be  active,  thus  reducing  friction.  The  upward  pulling 

effect  is  simulated  by  changing  the  anchor’s  lower  body  mass  according  to  the 
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height  of  the  last  chain  section  attached  to  the  anchor’s  shank.  This  measure  will 
be  used  as  an  indicator  of  the  direction  of  the  pulling  force.  When  pulling 
horizontally,  the  last  chain  section  will  be  low,  close  to  the  seabed.  The  more 
vertical  the  chain  pulls  the  anchor,  the  higher  the  last  chain  section  will  be, 
meaning  less  friction  applied  at  the  anchor,  simulated  by  decreasing  the  mass  of 
the  anchor’s  lower  part. 

Basic  controlling  functionality  was  added  to  YPSim,  allowing  the  user  to 
drop  and  heave  the  anchor,  using  a  chain  length,  number  of  sections  and  friction 
constant  that  are  previously  set  at  the  scenario  configuration  file.  For  the  scope 
of  this  thesis,  an  interactive  GUI  was  not  implemented;  however,  it  is  an 
important  component  to  be  added,  allowing  more  control  functionality,  such  as 
setting  the  chain  length  and  artificial  intelligence  to  simulate  the  Boatswain 
dialogue  during  the  anchoring. 
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Figure  37.  A  graphical  representation  of  the  anchor  and  chain  model 
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APPENDIX  D.  YP  PHYSICAL  MODEL 


The  actual  YP’s  physical  model  has  the  following  forces  and  torques, 
better  visualized  in  Figure  38. 
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Figure  38.  YP's  physical  model  diagram. 


•  Gravity:  applied  over  the  total  mass  of  the  YP  in  its  local  origin. 

•  Buoyance:  distributed  over  16  points  over  the  horizontal  plane  of 
the  YP.  For  each  point,  an  ODE  contact  joint  is  created  with 
parameters  that  simulate  a  floating  body,  meaning  a  highly  spongy 
joint.  Comparing  point’s  Z  coordinate  and  the  ocean  surface  at 
point’s  XY  position  calculate  the  point’s  depth,  which  is  used  to  set 
the  joint’s  depth.  Each  joint  is  attached  to  the  YP’s  body,  enabling 
the  floating  effect  over  the  ocean,  with  a  realistic  response  to  the 
swell. 

•  Propellers:  two  forces  are  applied  independently,  one  for  port  and 
another  for  the  starboard  engines.  These  forces  assume  a  fixed 
longitudinal  direction  (YP’s  Y  local  axis),  moving  forward  or 
backwards  proportional  to  the  respective  engine’s  RPM.  The  forces 
for  the  forward  and  backward  movements  have  different  parametric 
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equations,  using  the  engine  RPM  as  an  argument.  The  reason  for 
this  difference  is  in  the  propeller’s  profile,  designed  to  be  more 
effective  when  moving  forward.  These  forces  are  applied  at  the 
position  of  each  propeller,  relative  to  the  YP’s  origin. 

•  Rudders:  two  forces  are  applied,  one  for  each  rudder  (port  and 
starboard),  with  direction  equals  to  the  rudder’s  normal.  The 
magnitude  of  these  forces  is  calculated  separately,  proportional  to 
the  respective  water  flow  through  each  rudder.  The  water  flow  is 
given  not  only  by  the  YP’s  movement  over  the  water  but  also  by  the 
respective  propeller  when  engaged.  These  are  forces  applied  in 
local  coordinates,  at  the  position  of  the  rudders. 

•  Linear  Drag:  a  force  that  is  proportional  to  the  square  of  the  YP’s 
velocity  over  the  water  and  a  given  pair  of  friction  coefficients  (XY 
local  axis).  Friction  coefficients  for  the  X  component  of  the  force 
(lateral  drag)  is  much  higher  than  Y  component  (longitudinal  drag) 
as  expected  because  of  the  hull  geometry.  Another  important  effect 
simulated  is  the  use  of  different  longitudinal  components  for  forward 
or  backward  YP  movement.  The  hull  offers  much  less  resistance 
when  moving  forward  than  backwards.  The  velocity  vector  over  the 
water  is  calculated  subtracting  the  sea  current  velocity  from  the 
YP’s  body  linear  velocity  in  world  coordinates. 

•  Sea  current:  the  effect  caused  by  the  sea  current  is  not  result  of 
any  direct  force  or  torque  being  applied  at  the  YP’s  body.  Instead, 
simply  by  subtracting  the  sea  current  velocity  vector  from  the  YP’s 
linear  velocity  and  using  the  result  to  calculate  the  linear  drag  force, 
we  are  able  to  induce  the  desired  effect.  By  doing  subtraction,  the 
model  is  always  applying  dragging  forces  to  the  YP’s  body  that  are 
proportional  to  the  sea  current  velocity. 

•  Angular  Drag:  a  relative  torque  applied  in  the  YP’s  local  Z  axis,  with 
magnitude  proportional  to  the  square  of  YP’s  angular  velocity  in  its 
local  Z  axis  and  a  rotational  drag  coefficient.  Its  direction  is  the 
opposite  of  the  YP’s  rotation  in  the  Z  axis,  in  order  to  generate  the 
friction  effect.  Another  component  is  added  to  the  angular  drag, 
given  by  the  ability  to  a  boat  straighten  out  at  high  speeds.  This 
second  component  is  proportional  to  the  YP’s  linear  velocity  and 
the  angular  velocity. 

•  Wind  Linear:  a  force  applied  at  the  YP’s  origin,  with  direction  and 
magnitude  equal  to  the  apparent  wind  in  local  coordinates.  The 
force  vector  is  decomposed  into  XY  components  and  its  square 
multiplied  by  the  respective  friction  constant.  The  friction  constant  is 
given  by  the  YP’s  profile  over  the  water,  yielding  a  lateral 
component  greater  than  longitudinal. 
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•  Wind  Torque:  a  relative  torque  applied  in  the  YP’s  local  Z  axis,  with 
magnitude  proportional  to  the  magnitude  of  the  apparent  wind  and 
the  cube  of  its  angle.  The  torque  direction  is  given  by  the  sine  of  the 
apparent  wind  angle.  The  ending  result  is  the  simulated  natural 
tendency  that  the  YP  has  to  align  to  the  wind,  either  facing  it  or 
getting  it  from  astern. 

•  Rolling:  in  order  to  simulate  the  rolling  effect  that  ships  present 
during  turns  at  high  speeds,  a  relative  torque  in  the  Y  axis  was 
added  to  the  model.  The  torque  magnitude  is  proportional  to  the 
YP’s  linear  velocity  and  angular  velocity  in  the  Z  axis.  The  direction 
is  given  by  the  direction  of  the  turn  in  progress.  When  turning  to  the 
left,  a  positive  torque  in  the  local  Y  axis  is  produced,  while  right 
turns  make  it  negative  in  the  same  axis. 

•  Damping:  as  frequently  used  in  physical  simulations,  a  linear  and 
angular  damping  is  applied  to  the  YP’s  model,  avoiding  instability 
and  granting  a  natural  energy  dissipation  process  to  the  system. 
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APPENDIX  E.  NAVIGATION  RADAR 


We  implemented  the  YPSim  navigation  radar  using  a  raytracing  technique 
to  detect  contacts  and  display  them  on  the  screen.  The  Delta3D  dtCore::lsector 
class  was  used  to  generate  an  intersection  ray  starting  at  the  radar’s  antenna, 
pointed  to  the  antenna’s  Z  orientation.  The  length  of  the  ray  is  set  to  the  current 
radar  range  scale,  avoiding  detection  of  off-range  contacts.  Our  algorithm  then 
searches  for  the  first  intersection  point  that  occurred,  retrieving  its  XY 
coordinates  in  case  an  intersection  happened.  This  cycle  is  repeated  every 
simulation  frame,  updating  the  ray  with  a  new  orientation  coming  from  the 
antenna’s  rotation.  To  generate  the  radar  echo  on  the  screen,  we  used  a  Delta3D 
dtCore:: Particle  system,  with  particles  being  generated  at  the  contact’s  XY 
position,  now  mapped  to  the  radar  screen  local  coordinates.  Each  particle  is  set 
to  have  a  decay  time  of  one  antenna’s  rotation  cycle  (approximately  2.5 
seconds),  generating  the  pleasant  effect  of  a  real  radar  screen. 


Figure  39.  Screenshot  of  the  YPSim's  radar  in  a  HUD  mode. 


Ill 


The  radar  screen  can  be  visualized  as  a  heads-up  display  or  at  the  radar 
unit,  mounted  inside  the  YP’s  bridge,  according  to  user’s  selection.  We  used  a 
Delta3D  dtCore::Object  to  render  the  radar  screen  on  the  scene  graph.  The 
radar’s  3D  model  loaded  has  special  nodes  to  simulate  the  radar  sweep, 
electronic  bearing  line  (EBL),  variable  range  marker  (VRM)  and  ship’s  head 
marker  (Figure  39).  These  geometry  nodes  are  placed  under  DOFTransform 
OSG  nodes,  allowing  selected  transform  manipulation  during  the  runtime,  leading 
to  the  desired  simulated  effect  for  each  one  of  the  nodes.  The  range  scale 
indicator  was  implemented  using  geometries  for  each  digit,  controlled  by  OSG 
Switch  nodes.  EBL  and  VRM  values  are  displayed  on  the  screen  by  using 
objects  of  the  Delta3D  dtABC::LabelActor  class. 


Figure  40.  YPSim's  radar  screen  displayed  on  the  radar  unit,  inside 

the  bridge. 
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APPENDIX  F.  USER  ACCEPTANCE  QUESTIONNAIRE 


YPSim  User  Acceptance  Survey  Part  #: 


1.  Rank  (circle  one):  l'yr  2  lyr  3"Jyr  4*yr  2.  YP  Mentor  (circle  one):  Y  N 

3.  Do  you  play  video  games  frequently  (circle  one):  Y  N 

4.  Have  you  played  any  ship  simulator  game  before  (circle  one):  Y  N 

5.  How  much  time  do  you  need  aboard  for  familiarization  until  you  feel  comfortable  executing  a  task  for  the  first 

time  at  the  YP? 

a)  Between  10-30  minutes  b)  Between  30-60  minutes  c)  >  1  hour  d)  I  did  not  need  any  familiarization  time 

6.  In  your  opinion,  what  is  the  best  way  to  learn  navigation  and  ship  handling  skills  aboard  the  YP? 

a)  I  prefer  observe  my  colleagues  doing  the  tasks  and  try  to  extract  their  lessons  from  success  and  fail.  I  also 
feel  comfortable  about  asking  questions  to  senior  midshipmen  and/or  the  instructors. 

b)  I  prefer  observe  my  colleagues  doing  the  tasks  and  try  to  extract  their  lessons  from  success  and  fail.  I  don't 
feel  so  comfortable  about  asking  questions  to  senior  midshipmen  and/or  the  instructors. 

c)  I  prefer  doing  the  tasks  by  myself  and  I'm  not  afraid  of  doing  mistakes,  they  will  be  a  valuable  source  of  learning 
for  me. 

d)  I  prefer  doing  the  tasks  by  myself,  but  I'm  afraid  of  doing  mistakes,  causing  a  bad  impression  to  my  instructors 
and/or  colleagues. 

e)  Other  (explain): 


7.  Rate  your  agreement  with  the  following  statements  by  marking  an  X  in  one  block  for  each: 


Disagree 


A 

B 

C 

D 

E 

F 

G 

H 


I  feel  confident  that  my  knowledge  about  the  tasks 
executed  aboard  will  be  sufficient. 

Before  going  aboard,  I  have  complete  understanding  of  the 
tasks  I’ll  execute 

YP  hands  on  training  motivates  me 

YP  hands  on  training  is  important  to  learn  navigation  and  ship 
handling  skills 

I  feel  well  prepared  every  time  I  go  aboard  the  YP  for  training 

There  is  some  knowledge  gap  between  classroom  theory  and 
the  practice  aboard  the  YP 

The  number  of  YP  training  sessions  is  enough  to  understand 
the  theory  and  master  the  skills  of  navigation  and  ship 
Sometimes  I  want  to  execute  (or  repeat)  a  maneuver  onboard 
but  there  is  not  enough  time  to  do  that 


© 

© 

© 

© 

© 

© 

© 

© 


© 

© 

© 

© 

© 

© 

© 

© 


© 

© 

© 

© 

© 

© 

© 

© 


© 

© 

© 

© 

© 

© 

© 

© 


Agree 

© 

© 

© 

© 

© 

© 

© 

© 


Turn  page 
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8.  Rate  your  agreement  with  the  following  statements  by  marking  an  X  in  one  block  for  each: 


Disagree  Agree 


.  The  use  of  a  ship  driving  simulator  would  help  me  to  reduce 
any  knowledge  gap  between  classroom  and  the  hands  on 

0 

© 

© 

© 

© 

q  The  use  of  a  ship  driving  simulator  would  be  a  motivational 
tool  to  academy's  midshipmen 

If  1  had  a  ship  driving  game  simulator  in  which  1  was  able  to 

C  play  the  same  tasks  executed  aboard  the  YP,  1  would  use  it  to 
practice  before  going  aboard 

0 

0 

© 

© 

© 

© 

© 

© 

© 

© 

A  YP  simulator  is  not  important  and  will  never  help  me  to 

D  perform  better  aboard  the  YP 

The  use  of  a  YP  simulator  would  be  a  valuable  instructional 

E  resource  inside  the  classroom,  making  it  easier  to  better 
understand  procedures  and  maneuvers 

©  © 

©  © 

© 

© 

© 

© 

© 

© 

p  YPSim  graphics  quality  is  good 

© 

© 

© 

© 

© 

q  YPSim  can  be  a  valuable  training  tool 

0 

© 

© 

© 

© 

p|  Using  YPSim  gives  me  the  sensation  of  being  onboard  the  YP 

0 

© 

© 

© 

© 

|  If  1  had  a  version  of  YPSim  in  my  PC  1  would  play  it 

0 

© 

© 

© 

© 

j  The  YP's  movements  and  physics  response  in  YPSim  are  close 
to  the  reality 

0 

© 

© 

© 

© 

^  YPSim  indicators  are  easy  to  read  and  give  the  user  a  complete 
understand  about  the  YP  situation 

0 

© 

© 

© 

© 

^  All  information  needed  (controls,  sensores,  visualization, 
sound,...)  to  execute  the  tasks  are  available  on  YPSim 

0 

© 

© 

© 

© 

1^1  The  use  of  YPSim  can  motivate  midshipmen  and  make  them 

1  feel  closer  to  the  future  job  aboard  a  real  ship 

0 

© 

© 

© 

© 

Using  YPSim  will  be  a  waste  of  time,  no  simulation  can  replace 
the  hands  on  training  aboard  the  YP 

0 

© 

© 

© 

© 

q  YPSim  has  poor  quality  and  is  too  distant  from  a  good 
simulators  that  could  be  used  as  a  valid  training  tool 

0 

© 

© 

© 

© 

9.  Do  you  have  any  suggestions  for  improving  YPSim  as  a  training  tool? 


10.  Provide  any  comments  about  your  general  impression  of  YPSim  and  ideas  about  situations  where  this 
simulation  would  be  useful  to  train  or  provide  learning  to  you.  Please,  consider  the  possibility  of  using  it  as  a 
classroom  simulator,  instructional  resource  or  a  PC-game. 


Thank  you!!! 
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APPENDIX  G.  SURVEY  RESULTS 


The  distribution  of  the  answers  obtained  from  the  forty  participants  on  the 
user  acceptance  survey  is  graphically  represented  in  Table  14.  For  the  Likert 
scale  questions,  1  means  fully  disagrees  while  5  means  fully  agrees  with  the 
proposed  statement.  Open-ended  questions  were  not  summarized  here. 


Table  12.  Graphical  representation  of  the  user  acceptance  questionnaire  answers. 


Answers’  Dis 


ributions 


20 


I  io 


Grade  distribution 


15~ 


13 


12 


1 


■  1st  Year 

□  2nd  Year 

□  3rd  Year 

■  4th  Year 


□  non-mentor 

□  mentor 


100 

%  50 

0 


Gamer  Status 


62,5 


37,5 


□  Gamer 

□  Non-gamer 


Have  played  any  ship  simulator  before? 


□  Yes 

□  No 


Learning  style 


50  - 42£- 


% 


5,0 


10,0 


□  Observe  and  OK  to  ask 

□  Observe  but  not  OK  to  ask 

□  Doing  not  afraid  to  fail 
■  Doing  but  afraid  of  fail 
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SC  -  If  I  had  a  ship  driving  game  sim  I'd  use  it 


1 

2 


■  3 

■  4 

■  5 


% 


8F  -  YPSim  graphics  quality  is  good 


1 

2 

■  3 

■  4 

■  5 


8H  -  YPSim  gives  sensation  of  being  aboard 

27.5 


30 

20 

10 


20,0 

22,5 

■ 

22,5 

7.5 

1 

2 

■  3 

■  4 

■  5 
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81  - 1  would  play  if  I  had  a  version  on  my  PC 

60 


% 


40 

20 

0 


40,0 


0,0 


5,0 


27,5  27,5  I 


1 

2 

3 

■  4 

■  5 


80  -  YPSim  has  poor  training  quality 

37,5 
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APPENDIX  H.  HIERARCHICAL  TASK  ANALYSIS  (MAN  OVERBOARD  TASK) 


Table  13.  Hierarchical  Task  Analysis  for  the  Man  Overboard  task. 


Step 

Function 

User  Action/Task 

Remarks 

1 

Man  overboard  recovery  (Anderson  Turn) 

1.1 

Execute  Maneuver 

Conduct  the  MOB  maneuver  according 
to  procedures  in  shiphandling  manual 
for  a  MOB  recovery  during  day  time. 

1.1.1 

Check 

surroundings  for 

any  contact  or 
hazard 

OOD  goes  to  the  bridge  wing  of  the  side 
of  turn  and  visually  check  for  contacts 
or  navigation  hazards. 

This  evaluation  should  be  done  quickly  in  order  to  start 
turning  in  short  time  and  abbreviate  the  maneuver. 

1.1.2 

Move  the  ship’s 
stern  away  from  the 
MOB 

Order  the  Helmsman  full  turn  to  the 
same  side  the  MOB  felt. 

Helmsman  acknowledges  the  order. 

Rudder  indicator  goes  to  full  rudder  angle  at  the  side 
desired. 

Cues  from  the  horizon  movement  trigger  the  sensation  of 
moving  to  the  correct  direction. 

Fill  the  ship  rolling  to  the  correct  side,  another  good 
indicator  of  the  turning. 

1.1.3 

Increase  ship’s 

speed 

Order  “ALL  ENGINES  AHEAD  FLANK” 
to  the  Lee  Helmsman. 

Lee  Helmsman  acknowledges  the  order. 

Ship’s  speed  indicator  starts  to  increase. 

Acoustical  cues  from  the  engines  sound  changing  indicate 
acceleration. 

Visual  cues  from  the  ship’s  wake  increasing  also  helps. 

1.1.4 

Reduce  ship’s 

speed 

When  MOB  is  at  abeam  position,  order 
“ALL  ENGINES  AHEAD  2/3”  to  the  Lee 
Helmsman. 

Lee  Helmsman  acknowledges  the  order. 

Ship’s  speed  indicator  starts  to  decrease. 

Acoustical  cues  from  the  engines  sound  changing  indicate 
deceleration. 

Visual  cues  from  the  ship’s  wake  changing  helps. 
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Step 

Function 

User  Action/Task 

Remarks 

1.1.5 

Reduce  ship’s 

speed  again 

When  MOB  is  at  your  port/stbd-bow 
position,  order  “ALL  ENGINES  AHEAD 
1/3”  to  the  Lee  Helmsman. 

The  same  than  1.1.4. 

1.1.6 

Reduce  turning  rate 

Right  after  step  1.1.5,  order  the 
Helmsman  “EASY  YOUR  RUDDER.” 

Helmsman  acknowledges  the  order. 

At  this  time,  OOD  will  probably  be  at  the  bridge’s  wing,  with 
a  clear  view  of  the  MOB,  and  have  no  more  access  to  the 
ship’s  indicators.  OOD  must  rely  on  information  provided  by 
his/her  teammates.  A  very  good  visual  cue  is  the  rate  that 
the  MOB  approximates  to  ship’s  bow. 

1.1.7 

Steady  the  course 
and  approach  the 
MOB 

Order  the  Helmsman  “RUDDER 
AMIDSHIPS.” 

The  same  than  before,  from  this  point  OOD  makes  small 
corrections  to  keep  the  MOB  at  ship’s  bow,  slightly  to  the 
recovery  side  (port/stbd.). 

1.1.8 

Break  ship’s  inertia 

When  MOB  is  close  to  ship’s  bow, 
order  “ALL  ENGINES  STOP”  to  Lee 
Helmsman. 

OOD  feels  ship’s  speed  being  reduced  to  zero,  the 
deceleration  rate  needs  to  be  such  that  the  ship  is  stopped 
when  the  MOB  is  at  the  recovering  position.  This  is  very 
hard  to  achieve  without  reversing  the  engines  to  make  a 
good  stop. 

1.1.9 

Make  the  final 
approach  to  the 
recovery  position 

Assuming  the  rescue  swimmer  method 
for  recovery,  maneuver  the  ship  with 
rudder  and  engines  to  place  the  MOB 
close  to  15  yards  from  the  recovery 
station.  The  recovery  station  is  located 
at  the  forecastle,  at  the  side  chose  by 
OOD  to  pick-up  MOB. 

The  visual  cues  will  be  crucial  at  this  point,  doing  a  good 
maneuver  depends  upon  OOD’s  reaction  time  to  the  cues 
present.  Quick  reactions  tend  to  lead  in  maneuvers  that  are 
more  precise. 

1.1.10 

Recover  the  man 

Determine  the  Boatswain  to  recover  the 
MOB 

Boatswain  acknowledges  the  order. 

OOD  must  watch  for  not  using  engines  during  the  pick-up, 
avoiding  risk  of  hit  MOB  with  the  propeller. 

1.2 

Check  MOB 

bearing  and  range 
and  ship’s  state 

Evaluate  the  relative  bearing  of  the 
MOB  and  ship’s  movement.  Decide  if 
the  situation  matches  the  procedural 
conditions  to  act  changing  ship’s  course 

Collect  information  from  own  observation,  GPS  or 
Quartermaster  of  the  watch  (QOA),  plus  ship’s  indicators  for 
rudder  and  engine.  Mental  evaluation  for  changes  in  rudder 
and  engines  orders.  This  step  represents  a  continuous 
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Step 

Function 

User  Action/Task 

Remarks 

or  speed. 

processes  throughout  the  maneuver. 

1.3 

Check 

environmental 

conditions 

Determine  Junior  OOD  (JOOD)  to  read 
water  temperature  register,  time  of 
MOB  and  calculate  direction  and 
magnitude  of  the  wind. 

JOOD  acknowledges  the  order  and  report  the  information 
required. 

1.3.1 

Determine  the 

recovery  side 

Check  the  sea  state,  wind  conditions 
and  MOB  consciousness  to  decide 
which  side  to  approach  the  MOB 
(port/stbd.). 

Inform  Boatswain  the  recovery  side. 

The  visual  cues  are  very  important  in  this  action,  it  is 
important  to  be  able  to  check  the  wind  direction  and  sea 
state  just  by  looking  at  the  caps  of  sea  waves. 

During  the  recovery,  OOD  must  be  focused  in  keeping 
MOB  at  leeward,  since  the  wind  effect  over  the  ship  tend  to 
push  it  towards  the  MOB  in  this  case. 

1.4 

Execute 

administrative 

procedures 

Start  a  set  of  actions  that  are  not 
correlated  with  the  maneuver  cognitive 
processing. 

The  sequence  is  not  mandatory,  allowing  changes  between 
1.4.1,  1.4.2  and  1.4.3.  Step  1.4.4  comes  prior  to  1.4.5,  but 
could  be  executed  prior  to  the  any  other  in  this  group. 

1.4.1 

Plot  MOB  position 
on  chart 

Give  order  to  plot  the  MOB  position  on 
nautical  chart  and  GPS. 

Quartermaster  of  the  Watch  is  responsible  for  plotting  the 
MOB  position. 

1.4.2 

Make  six  short 
blasts 

Give  order  to  make  six  short  blasts  on 
ship’s  whistle. 

Lee-helmsman  is  responsible  for  making  the  blasts. 

1.4.3 

Drop  lifebuoy  and 
smoke  sign 

(assuming  day  light 
situation) 

Give  order  to  drop  a  lifebuoy  and  a 
smoke  sign  close  to  the  MOB’s  position. 

Junior  OOD  (JOOD),  the  OOD  assistant,  is  responsible  for 
dropping  lifebuoy  and  smoke  sign. 

1.4.4 

Hoist  OSCAR  flag 

Give  order  to  hoist  OSCAR  flag. 

Signal  Station  is  responsible  for  hosting  the  OSCAR  flag. 

1.4.5 

Disseminate  the 

MOB  situation 

Determine  JOOD  to  disseminate  “Ship’s 
MOB”  in  the  Power  Amplified  (PA) 
system. 

JOOD  acknowledges  the  order  and  executes  it. 

1.4.6 

Dismiss  stations. 

MOB  is  recovered,  MOB  determines  all 
stations  to  resume  normal  activities. 

Resume  ships  route,  course  and  speed. 
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APPENDIX  I.  HIERARCHICAL  TASK  ANALYSIS  (ANCHORING) 


Table  14.  Hierarchical  Task  Analysis  for  the  Anchoring  task. 


Step 

Function 

User  Action/Task 

Remarks 

2 

Anchoring 

2.1 

Pre-action 

Procedures. 

Acquire  all  important  information 
available  about  maneuver  (1  hour  prior 
to  scheduled  start). 

Conduct  a  “hot-briefing”  at  the  Bridge  with  the  Boatswain  and 
Navigator. 

2.1.1 

Check  anchoring 

position  in  the  nautical 
chart. 

Ask  Navigator  to  show  and  describe  the 
anchorage  in  the  nautical  chart. 

Conduct  a  mental  evaluation  of  the  proposed  plan  to  the 
Anchoring  maneuver,  check  safety  and  effectiveness  of  the 
route  to  anchorage. 

2.1.2 

Check  the  anchoring 
depth  and  nature  of 
the  seabed. 

Ask  Navigator  to  show  the  estimated 
depth  and  the  expected  nature  of 
seabed. 

Quickly  evaluate  the  data  provided,  checking  about  safety 
limits  and  ships  draught.  Calculate  the  necessary  scope  of 
chain  and  inform  Boatswain. 

2.1.4 

Check  expected  tide 
level  and  current. 

Ask  Navigator  about  the  expected  tide 
current  at  the  anchorage. 

Make  a  quick  evaluation  of  how  these  factors  will  affect  the 
maneuver. 

2.1.3 

Check  meteorological 
conditions. 

Check  the  last  records  of  wind  direction 
and  speed  and  expected  forecast  for  the 
next  hours. 

Make  a  quick  evaluation  of  how  these  factors  will  affect  the 
maneuver.  The  final  approach  to  the  anchorage  should  be 
facing  the  prevailing  factor  (wind  or  current). 

2.1.4 

Disseminate  OOD 

intentions. 

OOD  tell  Navigator  and  Boatswain 
his/her  maneuver  intentions. 

It  is  very  important  to  make  it  clear  so  everyone  is  able  to 
foresee  any  potential  safety  issue. 

2.2 

Navigate  to  the 

anchoring  position  and 
set  anchor. 

Conduct  the  ship  to  the  anchorage  giving 
orders  to  the  Helmsman  and  Lee 
Helmsman,  based  upon  the  Navigator’s 
suggestions. 

During  the  whole  period  of  navigation, 
OOD  reports  range  to  anchorage  (2000, 
1000,  500,  200,  100,  50  yards)  to  the 
Boatswain.  When  ship  reaches  the 
anchoring  position,  properly  set  anchor. 

Navigator  provides  a  complete  report  each  3  minutes  to  OOD, 
so  he/she  can  correct  course  and  speed  to  destination. 
Boatswain  acknowledges  the  range  to  anchorage  information, 
when  disseminated  by  OOD.  OOD  uses  navigation  radar  and 
binoculars  to  check  the  surrounding  environment  for  surface 
contacts  or  potential  navigation  hazards. 
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2.2.1 

Evaluate  ship’s  status 
and  decide 

OOD  creates  a  mental  picture  of  the 
ship’s  status  and  decides  whether  to 
apply  corrections  on  present  course 
and/or  speed. 

The  OOD  is  responsible  to  bring  the  ship  to  the  anchorage 
point  following  a  given  route.  When  ETA  (Estimated  Time  of 
Arrival)  is  required  to  get  there,  OOD  must  consider  eventual 
changes  in  speed,  if  not  he/she  will  apply  changes  on  course 
in  order  to  compensate  drifting  effects  from  wind  and/or 
current.  The  OOD  relies  mainly  on  information  coming  from 
the  Navigator  to  make  his/her  decisions  until  reaching  the 
anchorage.  OOD’s  perception  of  the  environment  will  help  by 
visual  observations,  assisted  by  binoculars,  and  navigation 
radar.  Boatswain  information  will  provide  guidance  after 
dropping  the  anchor.  There  are  three  standard  speed 
reductions  conditioned  to  the  distance  to  the  anchorage. 

2.2.2 

Adjust  course  and 
speed  (when  needed) 

OOD  gives  new  orders  to  Helmsman  and 
Lee  Helmsman,  for  course  to  steer  and 
engines  RPM  respectively. 

If  OOD  evaluates  that  a  change  on  course  and/or  speed  is 
required,  he/she  will  apply  it.  These  changes  can  be  made  to 
increase  safety  (avoiding  any  hazard  situation)  or  keep  ship  on 
navigation  route  and  schedule. 

2.2.3 

First  speed  reduction. 

At  1 ,000  yards  from  the  anchoring 
position,  reduce  ships  speed  to  6  knots, 
if  navigating  at  greater  speed.  Determine 
to  the  Lee  Helmsman  “ALL  ENGINES 
AHEAD  2/3.” 

Lee  Helmsman  acknowledges  the  order. 

Reduction  on  ship’s  wake  is  a  good  indicator  of  speed 
reduction.  Engine  sound  also  changes,  and  speedometer 
drops  to  6  knots. 

2.2.4 

Second  speed 

reduction. 

At  300  yards  from  anchorage,  OOD 
reduces  ship’s  speed  to  3  knots. 
Determine  to  the  Lee  Helmsman  “ALL 
ENGINES  AHEAD  1/3.” 

The  same  than  before,  but  now  speedometer  drops  to  3  knots. 

2.2.5 

Third  speed  reduction 

At  100  yards  from  the  anchoring  position, 
OOD  stops  all  engines.  Determine  to  the 
Lee  Helmsman  “ALL  ENGINES  STOP.” 
Disseminate  to  the  Boatswain  “STAND 
BY  TO  DROP  ANCHOR.” 

The  same  than  before,  but  now  ship  is  expected  to  gradually 
stop. 

Boatswain  acknowledges  the  order  from  the  forecastle. 

2.2.6 

Break  ship’s  inertia. 

At  50  yards  from  the  anchoring  position, 
break  the  inertia  by  reversing  all  engines. 
Determine  to  the  Lee  Helmsman  “ALL 
ENGINES  ASTERN  1/3.” 

Visual  cues  coming  from  the  water  movement  close  to  the  hull 
are  fundamental  to  OOD  perception  of  ship’s  stop.  Also,  if  ship 
is  close  to  shore,  OOD  can  align  two  ashore  objects  at  abeam 
and  check  their  relative  motions  to  assess  ship’s  longitudinal 

124 


Step 

Function 

User  Action/Task 

Remarks 

movement. 

2.2.7 

Drop  Anchor. 

Determine  Boatswain  to  drop  anchor. 
Determine  Lee  Helmsman  “ALL 
ENGINES  STOP.” 

When  OOD  feel  the  ship  moving  astern,  by  his/her  visual 
cues,  around  1  knot,  drop  anchor  is  ordered  to  Boatswain. 
Boatswain  acknowledges  the  order. 

Listen  the  anchor  drop  on  the  water  and  chain  unreeling  from 
windlass. 

2.2.8 

Set  the  anchor. 

Slightly  pull  the  anchor  by  moving  the 
ship  astern  at  very  low  speed. 

Providing  some  astern  engine  power  will  create  a  tension  in 
the  chain  and  this  will  allow  the  anchor  to  grip  the  seabed, 
holding  the  ship.  Observe  the  angle  that  the  chain  is  entering 
the  water,  this  is  a  very  good  indicator  if  the  chain  has  enough 
tension  or  not.  If  the  anchor  is  not  properly  gripped  at  the 
seabed,  the  ship  will  keep  moving  astern.  OOD  uses  visual 
cues  (water  movement  or  ashore  objects)  to  check  ship’s 
movement. 

Boatswain  frequently  reports  chain  status  (tension  and 
direction)  and  finally  if  the  anchor  is  properly  set  to  the 
seabed. 

2.3 

Receive  navigation 

report 

Listen  to  a  set  of  standardized 
information  concerning  ship’s  position 
relative  to  the  navigation  route. 

This  report  is  periodically  (usually  each  3  minutes)  issued  by 
the  Navigator  and  verbally  acknowledge  by  the  OOD. 

2.4 

Check  environment 

Observe  the  outside  environment 
seeking  for  relevant  information 
concerning  the  navigation.  Check 
navigation  radar  for  contacts  or  any  other 
navigational  information. 

This  environmental  check  is  executed  at  every  moment  OOD 
looks  outside,  and  more  consistently  right  after  step  2.3.  This 
check  of  the  surrounding  factors  is  important  to  support  OOD’s 
decisions  on  changing  course,  speed  and  evaluating  ship’s 
safety  condition  (avoiding  other  contacts). 

2.5 

Receive  Boatswain’s 
report  and  check 
Anchor  Buoy 

Listen  to  a  set  of  standardized 
information  concerning  the  anchor  and 
chain  status.  Visually  check  the  Anchor 
Buoy,  whenever  clear,  for  estimating 
anchor’s  position  relative  to  the  ship  and 
possible  drag. 

This  information  will  guide  OOD’s  decisions  at  the  final  stage 
of  the  navigation  to  the  anchorage  (when  Boatswain  reports 
ready  to  drop  anchor)  and  after  dropping  the  anchor.  From  the 
moment  the  anchor  is  dropped,  OOD  will  rely  on  Boatswain’s 
report  to  create  a  mental  picture  of  what  is  happening 
underwater.  Information  about  the  anchor  conditions  (holding 
or  dragging,  how  the  anchor  is  tending  -  "9  o'clock,"  "12 
o'clock,"  number  of  shots  of  chain,  etc.),  and  what  sort  of 
tension  is  on  the  anchor  chain  will  be  vital  to  OOD  set  the 
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anchor  (USNA,  1991). 

2.6 

Disseminate  “Anchor 
Stations” 

Determine  the  Junior  OOD  (JOOD)  to 
disseminate  “ANCHOR  STATIONS”  in 
the  PA  System,  (usually  five  Nautical 
Miles  from  anchorage). 

JOOD  acknowledges  the  order  and  disseminates  information. 

All  the  Stations  report  when  “ready.” 

Once  all  the  stations  (Navigator  and  Boatswain)  report  ready, 
OOD  is  under  satisfactory  conditions  to  anchor  the  ship. 

2.6.1 

Dismiss  stations 

The  OOD  determine  one  long  blast  on 
ship’s  whistle,  “shift  colors,”  display 
anchoring  shape/lights,  set  anchor  watch 
and  dismiss  all  stations  from  “Anchor 
Stations.” 

Happens  after  OOD  certification  that  ship  is  not  underway 
anymore  (primarily  provided  by  Navigator). 

OOD  hears  the  long  blast,  watch  national  ensign  and  union 
jack  hoisted  on  the  flagstaff  and  jackstaff,  respectively,  and 
watches  the  anchoring  shape/light  displayed. 
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